On Jan 16, 2016, at 4:36 PM, Arnd Bergmann <arnd@xxxxxxxx> wrote: > > On Saturday 16 January 2016 12:14:22 Andreas Dilger wrote: >>>> >>>> Sure, and nfs is a pain because of all it's internal use of >>>> timespecs, too. >>> >>> lustre is probably the worst. >> >> Lustre currently only has one-second granularity in a 64-bit field, >> so it doesn't really care about the difference between timespec or >> timespec64 at all. >> >> The only other uses are for measuring relative times, so the 64-bitness >> shouldn't really matter. >> >> Could you please point out what issues exist so they can be fixed. > > It's not really a bug that needs to be fixed, but more the general > issue of referencing inode->i_?time and attr->ia_?time and passing > them around. When we change the types in the inode and iattr from > timespec to timespec64, all assigments need to be modified, and lustre > has more of those assignments than any other file system I'm aware of. All of those accesses are with the LTIME_S() macro to get/set only the seconds field of the inode time, so it should only be a one-line patch? Cheers, Andreas
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail