On Mon, Sep 04, 2006 at 05:43:04PM -0400, Shaya Potter wrote:
> On Mon, 2006-09-04 at 22:33 +0200, Pavel Machek wrote:
> > On Mon 2006-09-04 09:28:26, Shaya Potter wrote:
> > > On Sun, 2006-09-03 at 11:05 +0000, Pavel Machek wrote:
> > > > > - Modifying a Unionfs branch directly, while the union is mounted, is
> > > > > currently unsupported. Any such change may cause Unionfs to oops and it
> > > > > can even result in data loss!
> > > >
> > > > I'm not sure if that is acceptable. Even root user should be unable to
> > > > oops the kernel using 'normal' actions.
> > >
> > > As I said in the other case. imagine ext2/3 on a a san file system
> > > where 2 systems try to make use of it. Will they not have issues?
> >
> > They probably will have issues (altrough I'm not sure, perhaps ext2
> > has been debugged enough), but they'll fix them (as opposed to
> > document that oopses are okay).
>
> I agree that unionfs shouldn't oops, it should handle that situation in
> a more graceful manner,
Agreed. The solution is to make the VFS little friendlier to stackable
filesystems. I'm not sure what the best way of accomplishing that would be.
There are some papers about it [1], but my gut feeling is that they are way
too invasive.
> but once the "backing store" is modified underneath it, all bets are off
> for either unionfs or ext2/3 behaving "correctly"
Exactly.
> where does one draw the line? I agree that stackable file systems make
> this a more pressing issue, as the "backing store" can be visible within
> the file system namespace as a regular file system that people are
> generally accustomed to interacting with.
The unionfs (as well as any other stackable filesystem) case can be fixed up
by making the VFS aware of the stack - for example, by having some kind of
stackable filesystem callbacks.
Josef 'Jeff' Sipek.
[1] http://www.isi.edu/people/johnh/PAPERS/Heidemann95e.html
--
Bad pun of the week: The formula 1 control computer suffered from a race
condition
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
