Messages in this thread | | | Subject | Re: [PATCH 8/8] fix handling of st_nlink on procfs root | From | (Eric W. Biederman) | Date | Wed, 08 Feb 2006 20:14:03 -0700 |
| |
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/
| |