On Sat, Nov 13, 2010 at 5:43 AM, J. Bruce Fields <bfields@xxxxxxxxxxxx> wrote:
> DCACHE_DISCONECTED dentries aren't always getting destroyed as soon as
> I'd have expected in the NFSv4 case.
>
> I'm not sure what the right fix is; any ideas? The below at least
> demonstrates the problem.
>
> --b.
>
> commit bb125ffbe5fc3f80ac7a5b20f51cc542c175cd49
> Author: J. Bruce Fields <bfields@xxxxxxxxxx>
> Date: Thu Nov 11 19:22:00 2010 -0500
>
> dput: free DCACHE_DISCONNECTED dentries sooner
>
> DCACHE_DISCONECTED dentries are normally left around for the benefit of
> future nfsd operations. But there's no point keeping them around once
> the inode has been deleted.
>
> Without this patch
>
> client$ mount -tnfs4 server:/export/ /mnt/
> client$ tail -f /mnt/FOO
> ...
> server$ df -i /export
> server$ rm /export/FOO
> (^C the tail -f)
> server$ df -i /export
> server$ echo 2 >/proc/sys/vm/drop_caches
> server$ df -i /export
>
> the df's will show that the inode is not freed on the filesystem until
> the last step, when it could have been freed after killing the client's
> tail -f. On-disk data won't be deallocated either, leading to possible
> spurious ENOSPC.
>
> This occurs because when the client does the close, it arrives in a
> compound with a putfh and a close, processed like:
>
> - putfh: look up the filehandle. The only alias found for the
> inode will be DCACHE_UNHASHED alias referenced by the filp
> associated with the nfsd open. d_obtain_alias() doesn't like
> this, so it creates a new DCACHE_DISCONECTED dentry and
> returns that instead.
This seems to be where the thing goes wrong. It isn't a hashed dentry at
this point here, so d_obtain_alias should not be making one.
I think the inode i_nlink games are much more appropriate on this side of
the equation, rather than the dput side (after all, d_obtain_alias is setting
up an alias for the inode).
Can you even put the link check into __d_find_alias?
- if (S_ISDIR(inode->i_mode) || !d_unhashed(alias)) {
+ if (S_ISDIR(inode->i_mode) || !inode->i_nlink ||
!d_unhashed(alias)) {
Something like that?
--
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
