lkml.org 
[lkml]   [1996]   [Nov]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Union file system
Date

In linux.dev.kernel, article <m0vStCS-0005FbC@lightning.swansea.linux.org.uk>,
alan@lxorguk.ukuu.org.uk (Alan Cox) writes:
>
> A union FS btw is _horrible_ to do well. Consider a process with an mmap
> of a union FS object that is replaced by a file elsewhere and keeping
> the mmap coherency correct. Now truncate the file at the same instant
> and enjoy
>
There's not much in an unionized file system that isn't already covered by
the usual file system semantics.

The only complication I can think of, offhand, is when two processes open a
file on an "underlying" file system and one then decides to write to the
thing. When that happens, the kernel obviously needs to copy the file. Now
what happens to the other process? Easy, it still has the inode of the old
file open and it'll keep that inode. This obviously means that no two
processes can open the same underlying file for writing because the kernel
would then have to create two distinct new files with the same name, but
IMHO that's not (much of) a problem.

Unix file system semantics don't work well with unionized file systems,
anyway. Use Plan 9 when you want to do that. ;-)

--
Matthias Urlichs \ noris network GmbH / Xlink-POP Nürnberg
Schleiermacherstraße 12 \ Linux+Internet / EMail: urlichs@noris.de
90491 Nürnberg (Germany) \ Consulting+Programming+Networking+etc'ing
PGP: 1024/4F578875 1B 89 E2 1C 43 EA 80 44 15 D2 29 CF C6 C7 E0 DE
Click <A HREF="http://info.noris.de/~smurf/finger">here</A>. 42

\
 
 \ /
  Last update: 2005-03-22 13:38    [W:0.871 / U:0.016 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site