>> 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.
Agreed.
>> 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?
That's why I don't plan on starting with that...
>> 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?
True, but that doesn't stop me wishing for it.
>> 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.
True.
>> 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.
Don't worry, I'm well aware of that. It doesn't stop me from wishing
for it...
> 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.
Depends what it's for...but I agree about the problems...
> The writable layer _has_ to be one, everybody has to agree on
> what each path means.
True.
>> 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).
Nope, that's the use of option (7) below, which you said you don't
want. This point is arguing for consistancy between the semantics of
R/O here and elsewhere.
>> 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.
Yet you say you want this feature above ???
> 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.
That depends what it's used for. Let me present two different possible
uses for what I called a "transparent mount"...
1. The scenario you appear to be basing your comments on, which
is to have a CD-ROM mounted with a hard drive over it, and
for files on the hard drive to take priority over matching
files of the same name in the same path on the CD-ROM.
2. The scenario that caused me to make my original proposal,
which is a single database too large to fit on a single CD,
so supplied as a three CD set. It's designed such that one
wishing to use it copies all three CD's onto one's hard
drive in the same directory and uses it from there. In my
case, I don't have sufficient hard drive space to do that.
If you analyse them, you will see that what makes sense for one is
often nonsense for the other, and they have completely different
requirements from the system as a result...
>> 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.
I suggest you think about what you're saying, as this comment is
totally the opposite of what you've said previously.
>>> 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.
One can easily know the direction one is going in without actually
knowing where one is going, and providing one knows the direction,
there is no good reason not to start walking - unless one intends to
fail before one starts, that is. I would hope you're not that sort of
person.
> In this case these operations _are_ the whole point of a rw
> filesystem.
If we were talking strictly about a R/W filesystem, then I'd agree
with you, but that isn't even necessary for the use I would have for
it, so arguments along those lines are meaningless.
>>> 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.
Only for the R/W version. It's meaningless for what I personally would
use it for, as the only common entries ARE directories.
> If it is too hard to solve, then the whole idea got nowhere.
Which shows the difference between us:
1. Following my logic, we would have a filesystem capable of
transparently mounting multiple CD's (or CD images) on top
of each other. I could make good use of this, and I'm sure
there are others who could use it as well.
2. Following your logic, we would have nothing.
I know which makes more sense to me.
> 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!)
There are probably other options that neither of us have thought of,
including some that we wouldn't even think of until we have something
to play with to see what happens.
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/