lkml.org 
[lkml]   [1999]   [Nov]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Transparent mounts
Hi Horst.

>> First, can I state that the response has easily proven that this
>> idea is in demand - 170 emails on the subject all interested in
>> it just can't mean anything else. It's also far too many for me
>> to reply to individually, hence my choosing these two to respond
>> to on behalf of them all, with snippets from one or two others
>> included...

> Careful! An idea that "just sounds cool" might be a nightmare to
> implement, or keep up to date, or introduce way too much bloat
> and be thrown out because of that.

Very true, but at least it's not something that nobody is interested
in. That would give me pause to think...

> BTW, as I stated, much of what this acomplishes can be got via a
> symlink farm. Why is that not enough here?

>> *** Horst Von Brandt commented...

> [My last name is 'von Brand'; lovercase 'von' and no 't']

My apologies.

>>> Many would like to mount a "live" filesystem from CD, and be
>>> able to "replace" files by ones on disk (i.e., / on CD, or the
>>> distribution; changes/updates on disk).

>> Many people have made the same mistake, so can I clarify the
>> above. If you read through it, you will note that I said...

>>>> Basically, I see it initially working such that for a transparent

> Please, lay out your full requirements, then talk about
> limitations of first prototypes.

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.

2. There can be any mixture of R/O and R/W partitions, with no
limit on the number of each.

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.

4. Where a program attempts to create a new file, it is created
on a designated read-write partition from those available.

5. The designated partition can be different for different users.

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.

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

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

>>> OTOH, semantics are hard to come by...

>>> - If I mount A, B, C; each containing file f. Which f do I see?
>>> Last one mounted, first one, individually selectable (how?)

>>> - What happens if I remount in another order later?

>>> - Assume the winning f above is the last one (from C). Now I
>>> delete f. What happens? Does f go away, do I see B's f? What
>>> if I unmount and then remount, does the change stick?

>>> AFAIKS, to do this cleanly would mean some kind of persistent
>>> overlay that keeps track of things, in addition to the
>>> filesystems themselves. The overlay keeps track of
>>> existing/nonexisting files, and points at them. But if you
>>> look a bit closer, this is almost the same as just populating
>>> a directory with symlinks to the real files elsewhere...

>> That is precicely why the above limitations on the INITIAL
>> implementation were suggested - they imply that these problems
>> can be left until later when an initial implementation is in
>> place and can be tried out.

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

>> *** Limitations

>> According to the documentation I've found or been pointed to
>> regarding the union file system, it includes the following
>> limitations for it to remain reliable:

>> 1. All partitions involved must be mounted at the same time.

>> Why? What is wrong with the idea of adding new partitions
>> to an existing set? Certainly, for the purpose that I'm
>> interested in it, this requirement is a killer.

> Agree.

Good.

>> 2. All partitions involved must be mounted in the same order
>> each time.

>> Again, why? OK, I can see that it's an easy way of dealing
>> with which partition to put changes on, but it's also an
>> extremely limiting one.

> It also handles the who overrides whom, and keeps some
> persistence. Not indispensable, but probably nice to have (if
> not, the "overlay" will have to be rebuilt each time. Urgh!)

Other than for dealing with name clashes involving non-directory
entries, this shouldn't be a problem.

>> 3. Although not explicitly stated, the examples shown all
>> imply that all partitions involved must be of the same
>> type.

>> I would certainly hope this is NOT the case.

> Agree.

Same here.

> Personally, I would be happier to see the following mounting
> semantics used for dealing with this:

>> 1. mount -o ro /dev/cdrom /mnt

>> Mounts an initial partition read-only as a basis for later
>> additions, or as a stand-alone mount.

>> 2. mount -o ro,trans /dev/cdrw /mnt

>> Mounts a second or later partition transparently on top of
>> the existing ones, also mounted read-only.

>> 3. mount -o rw,trans /dev/hda7 /mnt

>> Mounts a second or later partition transparently on top of
>> the existing ones, mounted read-write and labelled as the
>> one to be used for noting any changes.

Additionally:

4. mount -o ro,trans,cow /dev/hda7 /mnt

Mount a second or later partition transparently on top of
the existing ones, also mounted read-only, but specify
that if any files on this partition are modified, they are
to be copied to whatever is the current read-write mount
in this stack.

Note that "cow" = "copy on write" as per Linux standards.

>> The following restrictions could then be reasonably implemented:

>> 1. The bottom partition MUST be read-only. Given these semantics,
>> this is not a problem.

>> 2. In any stack of transparent mounts, AT MOST ONE may be
>> marked read-write. Any attempt to mount a second one as
>> read-write MUST fail. However, there is no problem with
>> a stack having no read-write partitions in it.
>>
>> Note that whilst I've used "trans" as the option to specify this
>> behaviour, I'm not fussed as to its spelling - "wibble" would serve
>> just as well.

> Sounds reasonable.

Good.

Best wishes from Riley.

PS: The kernel versions page is now back online at the URL below, and
includes separate sublists both for each kernel series, and for
each year of development.

+----------------------------------------------------------------------+
| There is something frustrating about the quality and speed of Linux |
| development, ie., the quality is too high and the speed is too high, |
| in other words, I can implement this XXXX feature, but I bet someone |
| else has already done so and is just about to release their patch. |
+----------------------------------------------------------------------+
* http://www.memalpha.cx/Linux/Kernel/


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

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