Re: [PATCH 12/13] sysfs: Propagate renames to the vfs on demand
From: Eric Biederman
Date: Mon Nov 09 2009 - 17:35:03 EST
On Mon, Nov 9, 2009 at 6:14 AM, Serge E. Hallyn <serue@xxxxxxxxxx> wrote:
> Quoting Tejun Heo (tj@xxxxxxxxxx):
>> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/