On Monday 28 September 2015 00:38:37 Dilger, Andreas wrote:
> >Changing this would unfortunately change the format in an incompatible
> >way, breaking all existing user space tools that access the data.
>
> It seems that it would be possible to fix this declaration to be
> compatible with current
On Sep 27, 2015, at 8:38 PM, Dilger, Andreas wrote:
> On 2015/09/27, 10:45 PM, "gr...@linuxhacker.ru"
> wrote:
>
>> From: Arnd Bergmann
>>
>> The lustre tracefile has a timestamp defined as
>>
>> __u32 ph_sec;
>> __u64 ph_usec;
>>
>> which seems completely backwards, as the micros
On 2015/09/27, 10:45 PM, "gr...@linuxhacker.ru"
wrote:
>From: Arnd Bergmann
>
>The lustre tracefile has a timestamp defined as
>
> __u32 ph_sec;
> __u64 ph_usec;
>
>which seems completely backwards, as the microsecond portion of
>a time stamp will always fit into a __u32 value, while
From: Arnd Bergmann
The lustre tracefile has a timestamp defined as
__u32 ph_sec;
__u64 ph_usec;
which seems completely backwards, as the microsecond portion of
a time stamp will always fit into a __u32 value, while the second
portion will overflow in 2038 or 2106 (in case of unsi
