On Mon, Jul 13, 2015 at 01:17:51PM -0500, Ben Myers wrote: > > For one thing, this patch does *not* check for i_nlink at all. > > I agree that no checking of i_nlink has the advantage of brevity. > Anyone who is using dentry.d_fsdata with an open_by_handle workload (if > there are any) will be affected. Translate, please. What does d_fsdata have to anything above? > > For another, there's no such thing as 'filesystems internal lock' for > > i_nlink protection - that's handled by i_mutex... And what does > > iget() have to do with any of that? > > i_mutex is good enough only for local filesystems. > Network/clustered/distributed filesystems need to take an internal lock > to provide exclusion for this .unlink with a .link on another host. > That's where I'm coming from with iget(). > > Maybe plumbing i_op.unlink with another argument to return i_nlink is > something to consider? A helper for the few filesystems that need to do > this might be good enough in the near term. ???? a) iget() had been gone since way back b) it never had been called by VFS - it's a filesystem's responsibility c) again, what the hell does iget() or its replacements have to do with dentry eviction? It does *NOT* affect dentry refcount. Never had. d) checks for _inode_ retention in icache are done by filesystem code, which is certainly free to use its locks. Incidentally, for normal filesystems no locks are needed at all - everything that changes ->i_nlink is holding a referfence to in-core inode, so in a situation when its refcount is zero and ->i_lock is held (providing an exclusion with icache lookups), ->i_nlink is guaranteed to be stable. e) why would VFS possibly want to know if there are links remaining after successful ->unlink()? I'm sorry, but you are not making any sense... -- 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
