Subject: Re: mount_union -> kernel panic
To: Bill Studenmund <firstname.lastname@example.org>
From: theo borm <email@example.com>
Date: 06/07/2006 09:35:42
Bill Studenmund wrote:
>>Apparently there hasn't for some time been the right combination of
>>annoyance with the current limitations among people with sufficient
>>filesystem clue to get the situation changed. I am low on the FS clue
>>curve myself (so far) but not on annoyance, and I would really love to
>>see "make the layer FSs genuinely useful" become a project, and
>>contribute to it what I could as well.
>Uhm, the fact that there aren't loops in the file system is more than a
>"File system limitation." Unix directories have always been a DAG, and a
>lot of stuff (userland tools, for instance) could break if they weren't.
I don't think we should be talking about introducing filesystem loops here;
more about properly checking that we don't create them under any
>While I agree it'd be best to not panic, and I think that you should be
>able to mount a unionfs layer over another one, things are going to need
>to stay DAGs for a while.
but how (and where) are cyclic dependencies being checked?
# mount_union test/sub test
mount_union: test/sub (/root/test/sub) and /root/test are not distinct paths
so this /is/ being checked
is " over -> over -> under " detected as being cyclic?
maybe there should be an additional check before mount if the object being
mounted refers to a different vnode than (any of) the underlying mount
>One thing which will lessen the difficulties is if we change create,
>remove, and rename processing to only look up the parent directories and
>let the file system look up the last components in its operation. That
>would change how we handle locking, and we could do directory lookups with
>unlocked vnodes for the most part.
I'm not quite certain that I understand how this would affect " over ->
over -> under "
union mounts. panic occurs on (ls) access not on mount.
With kind regards,