On Thu, Nov 05, 2015 at 10:14:24AM -0800, Darrick J. Wong wrote:
> ...but I guess nobody ever developed the e2fsprogs regression tests that Ted
> asked for, so none of the patches got merged. Ho hum.
I haven't forgotten, and it's been put on my "if you want to do it
right, you'll have to do it
On Thu, Nov 05, 2015 at 10:14:24AM -0800, Darrick J. Wong wrote:
> ...but I guess nobody ever developed the e2fsprogs regression tests that Ted
> asked for, so none of the patches got merged. Ho hum.
I haven't forgotten, and it's been put on my "if you want to do it
right, you'll have to do it
Darrick J. Wong wrote:
> There's been a patch to fix this for a very long time:
> http://thread.gmane.org/gmane.comp.file-systems.ext4/40978
So I see, though that patch doesn't also fix the encode case.
David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
On Thu, Nov 05, 2015 at 02:49:16PM +, David Howells wrote:
> The handling of extended timestamps in Ext4 is broken as can be seen in the
> output of the test program attached below:
>
> time extra bad decodegood decode bad encode good encode
> =
On Thursday 05 November 2015 14:49:16 David Howells wrote:
> Since the epoch is presumably unsigned, this has the slightly strange
> effect of, for epochs > 0, putting the 0x8000-0x range before
> the 0x-0x7fff range.
>
> This affects all kernels from v2.6.23-rc1 onwards.
The handling of extended timestamps in Ext4 is broken as can be seen in the
output of the test program attached below:
time extra bad decodegood decode bad encode good encode
= = = === ===
0 >
On Thu, Nov 05, 2015 at 02:49:16PM +, David Howells wrote:
> The handling of extended timestamps in Ext4 is broken as can be seen in the
> output of the test program attached below:
>
> time extra bad decodegood decode bad encode good encode
> =
Darrick J. Wong wrote:
> There's been a patch to fix this for a very long time:
> http://thread.gmane.org/gmane.comp.file-systems.ext4/40978
So I see, though that patch doesn't also fix the encode case.
David
--
To unsubscribe from this list: send the line "unsubscribe
On Thursday 05 November 2015 14:49:16 David Howells wrote:
> Since the epoch is presumably unsigned, this has the slightly strange
> effect of, for epochs > 0, putting the 0x8000-0x range before
> the 0x-0x7fff range.
>
> This affects all kernels from v2.6.23-rc1 onwards.
The handling of extended timestamps in Ext4 is broken as can be seen in the
output of the test program attached below:
time extra bad decodegood decode bad encode good encode
= = = === ===
0 >
10 matches
Mail list logo