Messages in this thread | | | From | "Sunil Khandwala" <> | Subject | Re: Transparent mounts | Date | Thu, 18 Nov 1999 15:16:52 -0600 |
| |
In a life long long ago.... I seem to remember that VMS had some kind of versioning file system where files had :xxx after them indicating version. Therefore for files that have the potential to eclipse one another something along the lines of the VMS version scheme could work.
--Sunil
-----Original Message----- From: Horst von Brand <vonbrand@inf.utfsm.cl> To: Riley Williams <rhw@memalpha.cx> Cc: Linux Kernel <linux-kernel@vger.rutgers.edu> Date: Thursday, November 18, 1999 11:34 AM Subject: Re: Transparent mounts
>Riley Williams <rhw@memalpha.cx> said: > >[...] > >> OK, here's what I would like to see this end up with: >> >> 1. Any number of partitions can be mounted on top of each other, >> with all files in all partitions visible. > >Agree, as long as no file "shadows" another one, etc. > >> 2. There can be any mixture of R/O and R/W partitions, with no >> limit on the number of each. > >How do you decide where to send writes? > >> 3. Where a program attempts to modify an existing file found on >> a R/W partition, it is directly modified on whichever of the >> partitions it is currently on. > >Messy semantics. How about several files with the same name? > >> 4. Where a program attempts to create a new file, it is created >> on a designated read-write partition from those available. > >OK, but several rw partitions is a mess anyway. > >> 5. The designated partition can be different for different users. > >Argh! I suspect that will _not_ work right with the current kernel >internals: The path to a file (as registered via dentries) does _not_ >register the user. Note that with your scheme, we both could be using files >with the very same path, but totally different files. This is just calling >for trouble, AFAIKS. > >The writable layer _has_ to be one, everybody has to agree on what each >path means. > >> Note that I very specifically have NOT dealt with the problem of what >> to do when a program attempts to modify an existing file on a R/O >> partition. I can see valid arguments for both of the following >> viewpoints: > >> 6. Elsewhere, R/O partitions do not permit files to be modified >> in any way, so why should it be different here. > >Yes, but you are trying to fake rw over ro anyway; the most use of this >would be for me to mount the CD from my distribution, and over it mount the >updates (files are gone, new ones appeared, others got changed). > >> 7. Why can't I boot from a CD with a hard drive mounted over it, >> and have the modifications made on the hard drive. > >I don't think so. I'd assume this fiddling will take some support from >userland, so better wait until init(8) has gotten the system up. I might be >mistaken. > >But having changes show up somehow on the filesystem is the most important >reason for having one in the first place, so getting rid of this feature >doesn't make sense. > >> I believe this problem will prove to require a separate mount option >> to allow users to specify which behaviour they require, and for this >> reason, the ONLY decision I would make wwould be to specify that (6) >> would be the default, with (7) chosen only if the other option is also >> specified at mount time. See later... > >Nope. Read-only is aleady possible, read-write has to be possible in a >reaonable way. > >> > The point of how to handle a multiple mount and modifications >> > (deleting, adding files; modifiying files; chmod/chown-ing them, >> > touch-ing them, ...) is too important to leave for "later, full >> > implementation": If no decent semantics can be defined, the >> > whole idea is moot IMVHO. > >> Personally, I do not believe there is any sense in discussing the >> above until some sort of initial implementation exists to enable the >> feasibility of most of the above to be determined in practice rather >> than theoretically. Too much of it could easily be wishful thinking. > >I disagree. If you don't know where you are going in the first place, why >start walking. In this case these operations _are_ the whole point of a rw >filesystem. > >[...] > >> > Without a clear goal to point at, I'm afraid this will just >> > degenerate into an unholy mess. > >> Unfortunately, I can't see any easy solution to the problem of name >> clashes for non-directories, although a reasonable solution for name >> clashes involving only directories would be to treat the directory in >> question as a separate transparent mount. > >OK, then _this_ is the core problem that has to be solved. If it is too >hard to solve, then the whole idea got nowhere. > >Posibilities are: > >- COW to a (the?) rw layer for files: This can be quite costly: If I overwrite > a few bytes on a large file might take a long time, fill up the rw layer >- rw layer keeps track of deleted files (not doable AFAIK with current > on-disk filesystems!) >-- >Dr. Horst H. von Brand mailto:vonbrand@inf.utfsm.cl >Departamento de Informatica Fono: +56 32 654431 >Universidad Tecnica Federico Santa Maria +56 32 654239 >Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 > >- >To unsubscribe from this list: send the line "unsubscribe linux-kernel" in >the body of a message to majordomo@vger.rutgers.edu >Please read the FAQ at http://www.tux.org/lkml/ >
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |