[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <D37C59DA-DFC7-4E18-8C53-5ACBC7B3FD4F@dilger.ca>
Date: Sat, 16 Jan 2016 19:30:55 -0700
From: Andreas Dilger <adilger@...ger.ca>
To: Arnd Bergmann <arnd@...db.de>
Cc: y2038@...ts.linaro.org, Dave Chinner <david@...morbit.com>,
linux-fsdevel@...r.kernel.org,
Deepa Dinamani <deepa.kernel@...il.com>,
linux-kernel@...r.kernel.org
Subject: Re: [Y2038] [RFC 02/15] vfs: Change all structures to support 64 bit time
On Jan 16, 2016, at 4:36 PM, Arnd Bergmann <arnd@...db.de> 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
Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)
Powered by blists - more mailing lists