linux-ext4 - query about truncate and orphan list

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAOiN93=uvi37EMuOYvd+Nr2up=giPikL+sLEOFTpqOzyHi+Tfw@mail.gmail.com>
Date:	Wed, 29 Aug 2012 14:52:22 +0530
From:	Ashish Sangwan <ashishsangwan2@...il.com>
To:	linux-ext4@...r.kernel.org
Subject: query about truncate and orphan list

I have a query about orphan list and truncate.
Currently these steps are performed in ext4_ext_truncate():
a) Start journal handle.
b) add inode to orphan list.
c) i_disksize is updated and inode is mark dirty.
d) actual truncate happen.
e) remove inode from orphan list.
f) handle stop.

If system crash during step d) will i_disksize is actually updated on disk?
AFAIK i_disksize might be updated on the journal but not on its
original location because the transaction is not commited yet.

If this is the case than what is the use of re-starting truncate
operation while processing orphan inode list?

PS: Also, there is function ext4_ext_truncate_extend_restart which may
commit the current transaction
in which case i_disksize would be updated but I am assuming there are
enough free journal blocks.

Thanks,
Ashish
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html