--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/