Re: Nfs filesystem corruption(?) after kmail crash

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 2 Jun 2008 15:05:17 +0200
"Alexander Borghgraef" <alexander.borghgraef.rma@xxxxxxxxx> wrote:

> Nobody? Anyone care to tell me how to interpret the strace stat cur output?
> 

> lstat64("cur", 0xbfb81cb4)              = -1 ENOENT (No such file or directory)

File doesn't exist...

If this is from "ls -l" or something like that, that means that the
client did a READDIR or READDIRPLUS and saw a "cur" entry in the
directory with a particular filehandle. It then went back and did a
stat() against that filehandle and it was gone. The two possibilities
are that something removed that directory in the interim (possibly
replacing it with a new "cur" directory), or that the filehandle was
bad for some reason. I'm not aware of any bugs causing the latter, so
the former is the most likely.

You would think that the client would just use the info returned by
READDIRPLUS to fill out the stat() info, but it doesn't because stat()
calls generate an on-the-wire getattr (unless noatime is specified).
Peter S. and I were talking about this the other day. IMO, this
probably ought to be changed.

Most likely, this is the race that Tom described. ext3 has 1s
granularity on timestamps. It's easy to do *many* NFS operations within
1s. You might consider switching to a local filesystem on the server w/
more granular timestamps if you have a lot of concurrent activity like
this.

Cheers,
-- 
Jeff Layton <jlayton@xxxxxxxxxx>
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux