From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: Andreas Dilger <adilger@dilger.ca>
Cc: Harshad Shirwadkar <harshadshirwadkar@gmail.com>,
linux-ext4@vger.kernel.org
Subject: Re: [PATCH] ext4: attempt to shrink directory on dentry removal
Date: Mon, 26 Aug 2019 22:27:57 -0400 [thread overview]
Message-ID: <20190827022756.GG28066@mit.edu> (raw)
In-Reply-To: <7303B125-6C0E-41C2-A71E-4AF8C9776468@dilger.ca>
On Sun, Aug 25, 2019 at 11:07:46PM -0600, Andreas Dilger wrote:
> This may not always detect empty directory blocks properly, because
> ext4_generic_delete_entry() will only merge deleted entries with the
> previous entry. It at least appears possible that if entries are not
> deleted in the proper order (e.g. in reverse of the order they are
> listed in the directory) there may be multiple empty entries in a block,
> and the above check will fail.
I don't think that's a problem. We always merge with the previous
entry, whether it's an empty/deleted entry or an in-use entry. So
long as all implementations do this, it works just fine. If there is
an ext2/3/4 implementation which deletes the entry by simply clearing
the inode number *without* merging with the previous one, it's
possible that we might get confused.
But that's easily fixed, too. In ext4_generic_delete_entry(), we just
need to add a check so that we check to see if the subsequent entry
(if it exists) has a zero de->inode value. If so, then we absorb the
current directory entry to include the deleted subsequent entry and
repeat the check.
- Ted
prev parent reply other threads:[~2019-08-27 2:28 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-21 18:27 [PATCH] ext4: attempt to shrink directory on dentry removal Harshad Shirwadkar
2019-08-24 2:31 ` Theodore Y. Ts'o
2019-08-26 2:46 ` harshad shirwadkar
2019-08-26 3:19 ` Theodore Y. Ts'o
2019-08-26 5:07 ` Andreas Dilger
2019-08-26 21:46 ` harshad shirwadkar
2019-08-27 2:38 ` Theodore Y. Ts'o
2019-08-27 20:53 ` Andreas Dilger
2019-08-27 2:27 ` Theodore Y. Ts'o [this message]
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=20190827022756.GG28066@mit.edu \
--to=tytso@mit.edu \
--cc=adilger@dilger.ca \
--cc=harshadshirwadkar@gmail.com \
--cc=linux-ext4@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.