lkml.org 
[lkml]   [1997]   [Aug]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: attempt to re-implement sillyrename for NFS in 2.1.*
Claus-Justus Heine wrote:
> The reason for those errors is the missing support for that
> "sillyrename" stuff that we had with the 2.0.* implementation of the
> nfs code.
>
> I dared to try to re-implement it.

I was also thinking of re-implementing the sillyrename, but I'm very
glad you did it instead :-)

One suggestion though ... I think it would be better for you to move the
sillyrename_cleanup to delete_inode. The main reason is that the
cleanup will block, possibly for quite a while, allowing the possibility
of the inode being put back in service. This has been a long-standing
race problem with put_inode.

The new delete_inode operation is protected from races by being removed
from the inode hashes. Since by definition the sillyrename operation is
essentially a deferred delete, it's appropriate to set nlink = 0 in
put_inode when i_count is 1 (going to 0). This will result in the call
to delete_inode, where you'll be safe from races for the cleanup.

Regards,
Bill

\
 
 \ /
  Last update: 2005-03-22 13:40    [W:0.400 / U:0.088 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site