lkml.org 
[lkml]   [1999]   [Nov]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Transparent mounts
Date
From
Riley Williams <rhw@memalpha.cx> said:
> 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. 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']

[...]

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

[...]

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


[...]

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

> 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!)

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

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

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