Re: [RFC 11/32] xfs: convert to struct inode_time
From: Roger Willcocks <hidden>
Date: 2014-06-02 18:58:24
Also in:
linux-fsdevel, linux-nfs, linux-xfs, lkml
From: Roger Willcocks <hidden>
Date: 2014-06-02 18:58:24
Also in:
linux-fsdevel, linux-nfs, linux-xfs, lkml
On Mon, 2014-06-02 at 11:04 -0400, Chuck Lever wrote:
NFSv2/3 timestamps are a pair of unsigned 32-bit values: one value for seconds since midnight GMT Jan 1, 1970, and one value for nanoseconds. (See the definition of nfstime3 in RFC 1813).
nfstime3 could be extended by redefining the otherwise unused
nanoseconds bits{31,30} as seconds{33,32}, to give a (signed) 34-bit
seconds field and an unsigned 30-bit nanoseconds field.
This could represent 1970 +/- 272 years.
Servers could indicate they can understand the extended time format by
adding a new FSINFO capability - FSF3_CANSETTIME_EX.
Clients would use a new SET_TO_CLIENT_TIME_EX time_how enum when sending
timestamps so old servers would be protected from new clients.
Old clients don't need to be protected from new servers because the
on-the-wire bit pattern for dates between 1970 and 2106 stays the same,
so they're no worse off than they were before.
Arguably the new server ought to clamp out-of-range timestamps before
sending them to old clients but that would need per-client state (and
nfs3 is stateless.)
--
Roger