Messages in this thread |  | | From | (Matthias Urlichs) | Subject | Re: Union file system | Date | 28 Nov 1996 14:06:03 +0100 |
| |
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
|  |