From: Valerie Aurora <vaurora@redhat.com>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: viro@zeniv.linux.org.uk, jblunck@suse.de, hch@infradead.org,
linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
tytso@mit.edu, linux-ext4@vger.kernel.org
Subject: Re: [PATCH 14/38] fallthru: ext2 fallthru support
Date: Wed, 4 Aug 2010 19:04:22 -0400 [thread overview]
Message-ID: <20100804230421.GC29353@shell> (raw)
In-Reply-To: <E1OgfCU-0000ko-Lu@pomaz-ex.szeredi.hu>
On Wed, Aug 04, 2010 at 04:44:10PM +0200, Miklos Szeredi wrote:
> On Tue, 15 Jun 2010, Valerie Aurora wrote:
> > Add support for fallthru directory entries to ext2.
>
> If a previously used ext2 filesystem with is mounted again then
> fallthroughs don't appear to work as expected. Stat returns ENOENT
> for these entries.
>
> Can't see anything obviously wrong with the code.
>
> >
> > XXX What to do for d_ino for fallthrus? If we return the inode from
> > the the underlying file system, it comes from a different inode
> > "namespace" and that will produce spurious matches. This argues for
> > implementation of fallthrus as symlinks because they have to allocate
> > an inode (and inode number) anyway, and we can later reuse it if we
> > copy the file up.
>
> That's an idea, but I guess it won't make everyone happy since it
> wastes both disk space and memory.
Hm, I should probably remove this comment - I've talked over the
symlink implementation with a few people and it seems like it
introduces more problems than it solves.
> One of the key differentiators for union mounts concept was that it
> doesn't duplicate inodes and dentries from the layers. With the
> directory copyup on lookup that's already partially lost, but that can
> be justified by the fact that non-directories usually far outnumber
> directories.
And it solves all the readdir() problems in one go. :)
> Another idea is to use an internal inode and make all fallthroughs be
> hard links to that.
>
> I think the same would work for whiteouts as well. I don't like the
> fact that whiteouts are invisible even when not mounted as part of a
> union.
I don't know if this helps, but I just wrote support for removing ext2
whiteouts and fallthrus using tune2fs and e2fsck. I think this does
what people want from a "visible" whiteout feature without adding more
complexity to the VFS. It also takes away all consideration of race
conditions and dentry conversion that happens with online removal of
whiteouts and fallthrus.
What are your thoughts on what a visible whiteout/fallthru would look
like?
Thanks,
-VAL
next prev parent reply other threads:[~2010-08-04 23:04 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1276627208-17242-1-git-send-email-vaurora@redhat.com>
2010-06-15 18:39 ` [PATCH 10/38] whiteout: Split of ext2_append_link() from ext2_add_link() Valerie Aurora
2010-06-15 18:39 ` [PATCH 11/38] whiteout: ext2 whiteout support Valerie Aurora
2010-07-13 4:24 ` Ian Kent
2010-07-19 22:14 ` Valerie Aurora
2010-06-15 18:39 ` [PATCH 14/38] fallthru: ext2 fallthru support Valerie Aurora
2010-07-13 4:30 ` Ian Kent
2010-08-04 14:44 ` Miklos Szeredi
2010-08-04 22:48 ` Valerie Aurora
2010-08-05 10:36 ` Miklos Szeredi
2010-08-05 23:30 ` Valerie Aurora
2010-08-06 8:15 ` Miklos Szeredi
2010-08-06 17:16 ` Valerie Aurora
2010-08-06 17:44 ` Miklos Szeredi
2010-08-04 23:04 ` Valerie Aurora [this message]
2010-08-05 11:13 ` Miklos Szeredi
2010-08-06 17:12 ` Valerie Aurora
2010-08-17 22:27 ` Valerie Aurora
2010-08-18 8:26 ` Miklos Szeredi
[not found] <1277492728-11446-1-git-send-email-vaurora@redhat.com>
2010-06-25 19:05 ` Valerie Aurora
[not found] <1281134124-17041-1-git-send-email-vaurora@redhat.com>
2010-08-06 22:35 ` Valerie Aurora
2010-08-07 0:28 ` Andreas Dilger
2010-08-08 16:40 ` Valerie Aurora
[not found] <eVJmW-3Lf-15@gated-at.bofh.it>
[not found] ` <eVJmW-3Lf-19@gated-at.bofh.it>
[not found] ` <fdNs6-5F1-7@gated-at.bofh.it>
[not found] ` <fdVfY-pv-23@gated-at.bofh.it>
[not found] ` <fe6Ep-cD-13@gated-at.bofh.it>
[not found] ` <fiCPo-73x-17@gated-at.bofh.it>
[not found] ` <fiMc1-6ip-7@gated-at.bofh.it>
2010-08-18 23:24 ` Bodo Eggert
2010-08-19 2:03 ` J. R. Okajima
2010-08-24 17:21 ` Valerie Aurora
2010-08-26 9:53 ` Bodo Eggert
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=20100804230421.GC29353@shell \
--to=vaurora@redhat.com \
--cc=hch@infradead.org \
--cc=jblunck@suse.de \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=tytso@mit.edu \
--cc=viro@zeniv.linux.org.uk \
/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