[...]
> 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/