Re: [PATCH] ext4: always set inode of deleted entry to zero

Re: [PATCH] ext4: always set inode of deleted entry to zero

[Theodore Ts'o]

On Wed, May 15, 2019 at 10:00:00PM +0800, Liu Song wrote:
> Although the deleted entry can not be seen by changing
> the rec_len of the parent directory entry. However we
> can piggyback set the entry's inode to 0. There is no
> harm and an entry with an inode of 0 means that the
> entry has been deleted and more reliable.
> 
> Signed-off-by: Liu Song <liu.song11@zte.com.cn>

What are the circumstances where this is "more reliable"?  In other
words, what problem are you trying to solve?  The fact that we don't
zero the inode number, but simply make the directory entry "disappear"
if possible is actually deliberate.

The goal was to give careless sytem administrators one last saving
throw (sorry, American English figure of speach; see [1] for an
explanation) against accidental mistakes, ifh they can shutdown their
system fast enough.

[1] https://en.wikipedia.org/wiki/Saving_throw

This doesn't actually work all that well these days, admittedly
because of how ext4_truncate works.  (See the debugfs man page for
lsdel for more details.)  However, I've always had the thought that if
someone wanted to implement a hack where all of the bitmap blocks that
would need to be zero could fit in a transaction, we wouldn't need to
update the extent tree blocks and indirect blocks, and could
significantly simplify the how many blocks might need to be modified
when deleting a file --- and make lsdel something that could work in
emergency circumstances again.

						- Ted