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 
circimstance

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

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 
point(s)

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

Theo.