Subject: [nfsv4] Re: nfsv4 Digest, Vol 17, Issue 4

From: Tony Reix <[email-masked]>
Date: Mon, 05 Sep 2005 18:23:52 +0200

> Linux EXT3 may have issues with change time... as a way to implement
> consistency. The V4 protocol requires a real change attribute. Bruce
> Fields said there is a client checking change time in a single compound
> after mod (?) and it is failing to detect change? Spencer observes
> we shouldn't try to fix broken file systems in protocol. (Aside
> from Brent Welch - is there a client flush operation? - yes, session
> bring down signals to server to reap all state held for that client).
> 
> David Black said blocks draft is hakey jakey.

A colleague working on EXT3 says that there is a known problem with
ext2/ext3: the date of a file is stored with a precision of ... 1
second. (a well-known problem for Makefile).

No fix seems available. It appears in the "TODO" list ...

Tony

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: "J. Bruce Fields" <[email-masked]>
Date: Mon, 5 Sep 2005 15:29:27 -0400

> No fix seems available. It appears in the "TODO" list ...

Yep, that's exactly our problem--the mtime is the only thing the
filesystem gives us that's remotely suitable as a change attribute, but
it only has a 1-second resolution on ext3 right now.  Argh.

--b.