On Tue, Jan 19, 2016 at 9:12 PM, Deepa Dinamani wrote:
>
> On Tue, Jan 19, 2016 at 2:25 PM, Arnd Bergmann wrote:
>> On Wednesday 20 January 2016 07:49:46 Dave Chinner wrote:
>>> On Mon, Jan 18, 2016 at 09:27:13PM -0800, Deepa Dinamani wrote:
>>> > On Mon,
On Tue, Jan 19, 2016 at 11:25:02PM +0100, Arnd Bergmann wrote:
> On Wednesday 20 January 2016 07:49:46 Dave Chinner wrote:
> > You're doing it wrong. fat_time_fat2unix() still gets passed
> > >i_mtime, and the function prototype is changed to a
> > timespec64. *Nothing else needs to change*,
On Thursday 21 January 2016 10:06:32 Dave Chinner wrote:
>
> IOWs, you're now finally suggesting doing the *simple conversion*
> I've been suggesting needs to be made *since the start* of this
> long, frustrating thread, except you *still want to abstract the
> timestamp unnecessarily*.
>
> For
On Mon, Jan 18, 2016 at 09:27:13PM -0800, Deepa Dinamani wrote:
>
>
> On Mon, Jan 18, 2016 at 5:38 PM, Dave Chinner wrote:
> > On Mon, Jan 18, 2016 at 10:46:07PM +0100, Arnd Bergmann wrote:
> >> On Tuesday 19 January 2016 08:14:59 Dave Chinner wrote:
> >> > On Mon, Jan 18,
On Mon, Jan 18, 2016 at 2:56 AM, Arnd Bergmann wrote:
> On Sunday 17 January 2016 22:09:26 Deepa Dinamani wrote:
>> Based on the discussion, here is how I propose to proceed:
>>
>> 1. Series for timestamp range check and clamping
>> 2. Bug fixing patches like change all
On Monday 18 January 2016 09:40:12 Deepa Dinamani wrote:
> On Mon, Jan 18, 2016 at 2:56 AM, Arnd Bergmann wrote:
> > On Sunday 17 January 2016 22:09:26 Deepa Dinamani wrote:
> >> Based on the discussion, here is how I propose to proceed:
> > Sounds good to me. Step 3 of course is
On Mon, Jan 18, 2016 at 10:46:07PM +0100, Arnd Bergmann wrote:
> On Tuesday 19 January 2016 08:14:59 Dave Chinner wrote:
> > On Mon, Jan 18, 2016 at 08:53:22PM +0100, Arnd Bergmann wrote:
> > > 3. for each file system that uses struct timespec internally to pass
> > >around inode timestamps,
On Tuesday 19 January 2016 08:14:59 Dave Chinner wrote:
> On Mon, Jan 18, 2016 at 08:53:22PM +0100, Arnd Bergmann wrote:
> > On Monday 18 January 2016 09:40:12 Deepa Dinamani wrote:
> > > On Mon, Jan 18, 2016 at 2:56 AM, Arnd Bergmann wrote:
> >
> > I agree it's ugly and fragile
On Mon, Jan 18, 2016 at 08:53:22PM +0100, Arnd Bergmann wrote:
> On Monday 18 January 2016 09:40:12 Deepa Dinamani wrote:
> > On Mon, Jan 18, 2016 at 2:56 AM, Arnd Bergmann wrote:
> > > On Sunday 17 January 2016 22:09:26 Deepa Dinamani wrote:
> > >> Based on the discussion, here is
Based on the discussion, here is how I propose to proceed:
1. Series for timestamp range check and clamping
2. Bug fixing patches like change all CURRENT_TIME use cases to
current_fs_time()
3. Patches for vfs to use timespec64 internally (maybe a series, if
required)
4. Patches that change all
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
On Friday 15 January 2016 13:49:37 Dave Chinner wrote:
> On Thu, Jan 14, 2016 at 11:46:16PM +0100, Arnd Bergmann wrote:
> > On Friday 15 January 2016 08:00:01 Dave Chinner wrote:
> > > On Thu, Jan 14, 2016 at 05:53:21PM +0100, Arnd Bergmann wrote:
> > > > On Thursday 14 January 2016 08:04:36 Dave
On Fri, Jan 15, 2016 at 06:01:36PM +0100, Arnd Bergmann wrote:
> On Friday 15 January 2016 13:27:34 Dave Chinner wrote:
> > The point I'm making is that we'll have to modify all the existing
> > filesystem code to supply a valid timestamp range to the VFS at
> > mount time for the range
On Thursday 14 January 2016 08:04:36 Dave Chinner wrote:
> On Wed, Jan 13, 2016 at 08:33:16AM -0800, Deepa Dinamani wrote:
> > On Tue, Jan 12, 2016 at 07:29:57PM +1100, Dave Chinner wrote:
> > > On Mon, Jan 11, 2016 at 09:42:36PM -0800, Deepa Dinamani wrote:
> > > > > On Jan 11, 2016, at 04:33,
On Wednesday 13 January 2016 17:27:16 Dave Chinner wrote:
> > I think
> > it was more than that when I first looked, so it's between 0.2% and 0.3%
> > of savings in total memory, which is certainly worth discussing about,
> > given the renewed interest in conserving RAM in general. If we want to
On Wed, Jan 13, 2016 at 08:33:16AM -0800, Deepa Dinamani wrote:
> On Tue, Jan 12, 2016 at 07:29:57PM +1100, Dave Chinner wrote:
> > On Mon, Jan 11, 2016 at 09:42:36PM -0800, Deepa Dinamani wrote:
> > > > On Jan 11, 2016, at 04:33, Dave Chinner wrote:
> > > >
> > > >> On Wed,
On Tue, Jan 12, 2016 at 07:29:57PM +1100, Dave Chinner wrote:
> On Mon, Jan 11, 2016 at 09:42:36PM -0800, Deepa Dinamani wrote:
> > > On Jan 11, 2016, at 04:33, Dave Chinner wrote:
> > >
> > >> On Wed, Jan 06, 2016 at 09:35:59PM -0800, Deepa Dinamani wrote:
Summarizing, here
On Tue, Jan 12, 2016 at 10:27:07AM +0100, Arnd Bergmann wrote:
> On Tuesday 12 January 2016 19:29:57 Dave Chinner wrote:
> >
> > This is what I meant about premature optimisation - you've got a
> > wonderfully complex solution to a problem that we don't need to
> > solve to support timestamps
On Mon, Jan 11, 2016 at 09:42:36PM -0800, Deepa Dinamani wrote:
> > On Jan 11, 2016, at 04:33, Dave Chinner wrote:
> >
> >> On Wed, Jan 06, 2016 at 09:35:59PM -0800, Deepa Dinamani wrote:
> >> The current representation of inode times in struct inode, struct iattr,
> >> and
> On Jan 11, 2016, at 04:33, Dave Chinner wrote:
>
>> On Wed, Jan 06, 2016 at 09:35:59PM -0800, Deepa Dinamani wrote:
>> The current representation of inode times in struct inode, struct iattr,
>> and struct kstat use struct timespec. timespec is not y2038 safe.
>>
>> Use
On Wed, Jan 06, 2016 at 09:35:59PM -0800, Deepa Dinamani wrote:
> The current representation of inode times in struct inode, struct iattr,
> and struct kstat use struct timespec. timespec is not y2038 safe.
>
> Use scalar data types (seconds and nanoseconds stored separately) to
> represent
21 matches
Mail list logo