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-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
