[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070731105309.GA6980@thunk.org>
Date: Tue, 31 Jul 2007 06:53:09 -0400
From: Theodore Tso <tytso@....edu>
To: Jan Blunck <jblunck@...e.de>
Cc: linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
Bharata B Rao <bharata@...ux.vnet.ibm.com>
Subject: Re: [RFC 12/26] ext2 white-out support
On Tue, Jul 31, 2007 at 09:44:36AM +0200, Jan Blunck wrote:
> Ok, this is pretty similar to the way I implemented this for tmpfs. The
> problem is that the union mount code is explicitly checking if the filesystem
> is supporting whiteout. I used to use a new filesystem flag (FS_WHITEOUT) for
> this but thought that disk filesystem like ext2/3/4 will have problem with
> that if you mount an old image. So I guess I still need a feature flag.
Without the method I described to you, *any* ext2/3/4 filesystem will
support whiteouts (as long as you have the support code compiled into
the kernel :-), so there's no need for a feature flag.
> > I wouldn't bother with setting the directory type field to be DT_WHT,
> > given that they will never be returned to userspace anyway.
>
> At the moment I still rely on this for the current readdir implementation.
> Viro already said that he doesn't want to see this (the readdir changes) in
> the kernel but in userspace.
Life gets very messy if you have to do this in userspace. Example:
statically linked programs that were compiled with a version of glibc
that didn't know about whiteout records. Unfortunately, the memory
needed to to collate directories entries so that whiteout records can
be dropped is painful enough that completely understand why Al doesn't
want to see this in userspace. Unfortunately this is going to be one
of those things that will make union mounts problematic, compared to
something like unionfs.
- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists