Re: [PATCH 12/13] sysfs: Propagate renames to the vfs on demand

[Eric Biederman <ebiederm@aristanetworks.com>]

On Mon, Nov 9, 2009 at 6:14 AM, Serge E. Hallyn <serue@us.ibm.com> wrote:
> Quoting Tejun Heo (tj@kernel.org):
>> Hello,
>>
>> Eric W. Biederman wrote:
>> > It isn't what I want but it is what the VFS requires.  If let the vfs
>> > continue on it's delusional state we will leak the vfs mount and
>> > everything mounted on top of it, with no way to remove the mounts.
>>
>> This is caused by not having any way to prevent deletion on
>> directories with submounts, right?  How does other distributed
>> filesystems deal with directories with submounts going away underneath
>> it?
>
> Ooooh.  I see, I was thinking only about the rename case, and forgot
> this was the path for deleted files, too.  For the rename case it
> should be ok to let the dentry be put since the submounts will be
> accessible at the new location, right?  Should that be handled
> separately?

No in the rename case it isn't ok to let the dentry be discarded put as mounts
are implemented using a hash of the struct dentry's address, and if you aren't
the mount point you are referenced as d_parent.

For rename I am slightly better than NFS.  sysfs does not support hard
links so if I am looking up the new name I can look for a preexisting
dentry for my
inode and if I find one I call d_move on it to lazily perform the rename.

Eric