Re: [PATCH 8/8] fix handling of st_nlink on procfs root

[ebiederm@xmission.com (Eric W. Biederman)]

Al Viro <viro@ftp.linux.org.uk> writes:

> On Wed, Feb 08, 2006 at 06:04:36PM -0700, Eric W. Biederman wrote:
>> There are some other similar problems still in /proc.
>> 
>> In my pid namespace work I have some managed to clean most of
>> this up, and finally split proc into two filesystems.
>> 
>> The only was I was able to get the union to work was
>> to let lookup return files in an internal mount.
>> 
>> The only problem was that /proc/irq/..  != /proc/
>
> That's not the only problem here, unfortunately.

Well at the moment it seems to be.  Basically a case of everything
seems to work but the semantics are weird and ugly, and not worth
doing if the legacy semantics are not maintained.

>> I will finish all of this up shortly but do you know a good
>> way to do a union mount when we mount proc?
>
> Not transparently; mount(2) should _not_ mount two filesystems at once.
> Note that you'll run into serious problems as soon as you try to mount/umount/
> mount --move the stuff there.  And doing unionfs <spit> approach will cause
> fsckloads of fun issues with lifetimes.

:)

Do you know if there is anything in what autofs does for mounts that
could be reused.

To a certain extent it would work find if I had a mount point and
all of the legacy directories were symlinks to it.

Anyway there are lots of possibilities and I will work something
out before it makes into the stable kernel.

I keep having the feeling that I might just wind up with everything
making sense under proc as I create more namespaces :)

Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/