[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090519121504.GO16526@bolzano.suse.de>
Date: Tue, 19 May 2009 14:15:04 +0200
From: Jan Blunck <jblunck@...e.de>
To: Arnd Bergmann <arnd@...db.de>
Cc: Miklos Szeredi <miklos@...redi.hu>, linux-kernel@...r.kernel.org,
linux-fsdevel@...r.kernel.org, viro@...iv.linux.org.uk,
bharata@...ibm.com, dwmw2@...radead.org, mszeredi@...e.cz,
vaurora@...hat.com
Subject: Re: [PATCH 00/32] VFS based Union Mount (V3)
On Tue, May 19, Arnd Bergmann wrote:
> On Tuesday 19 May 2009, Jan Blunck wrote:
> > > So this means that the topmost branch always needs to be writable,
> > > right? It isn't possible to make a union of two iso9660 filesystems,
> > > for example?
> >
> > Exactly. Although, you can do that with the help of tmpfs on top of the two
> > iso9660 filesystems.
>
> But how do you get there? You can mount the tmpfs on top of two iso9660
> file systems, but it seems that you wouldn't be able to get the two
> stacked on top of each other in the first place.
Well, at the moment you can stack them but readdir will fail every time you
call it ... I think this is just a question of policy if we want to allow that
or not.
> Also, by mounting a tmpfs on top, wouldn't you you violate the requirement
> for persistent inode numbers again?
There is no requirement for persistent unique inode numbers except if you want
to export the union again. This is something that is out of scope of this
implementation. If you are going to export a union mounted filesystem, you
only export the topmost filesystem.
> > Or by adding fake write support to iso9660 ...
>
> This would work, but you'd have to do this for each file system if you want
> to be able to use it as the top of the union while backed by a read-only
> block device or when you don't want it to be written.
I know that the requirement for the topmost filesystem to be able to create
directories and fill them with fallthrus is an unattractive one. On the other
hand this is the cost that you have to pay at the moment to get this kind of
functionality. This implementation will not help with all use-cases. Its focus
is to get certain use-cases right.
--
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