linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Theodore Ts'o" <tytso@mit.edu>
To: Liu Song <fishland@aliyun.com>
Cc: adilger.kernel@dilger.ca, linux-ext4@vger.kernel.org,
	linux-kernel@vger.kernel.org, liu.song11@zte.com.cn
Subject: Re: [PATCH] ext4: always set inode of deleted entry to zero
Date: Wed, 15 May 2019 23:17:37 -0400	[thread overview]
Message-ID: <20190516031737.GA24832@mit.edu> (raw)
In-Reply-To: <20190515140000.3611-1-fishland@aliyun.com>

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

           reply	other threads:[~2019-05-16  3:17 UTC|newest]

Thread overview: expand[flat|nested]  mbox.gz  Atom feed
 [parent not found: <20190515140000.3611-1-fishland@aliyun.com>]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190516031737.GA24832@mit.edu \
    --to=tytso@mit.edu \
    --cc=adilger.kernel@dilger.ca \
    --cc=fishland@aliyun.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=liu.song11@zte.com.cn \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).