On Jan 23, 2018, at 11:32 PM, Mark H Weaver wrote:
> Andreas Dilger writes:
>
>> On Jan 23, 2018, at 1:44 AM, Mark H Weaver wrote:
>>> Andreas Dilger writes:
>>>
On Jan 20, 2018, at 5:06 PM, Mark H Weaver wrote:
> Yes, on Btrfs I reliably see (st_blocks == 0) on a recently written,
Hi Mark,
> Andreas Dilger wrote:
> > We considered it a bug in ext4 and Lustre on the basis that it broke
> > existing tools (tar, and AFAIR cp) that were working fine when
> > delayed allocation and inline data features were not enabled. Since
> > we were in a position to fix the filesystems fas
Hi Andreas,
Andreas Dilger writes:
> On Jan 23, 2018, at 1:44 AM, Mark H Weaver wrote:
>> Andreas Dilger writes:
>>
>>> On Jan 20, 2018, at 5:06 PM, Mark H Weaver wrote:
Yes, on Btrfs I reliably see (st_blocks == 0) on a recently written,
mostly sparse file with size > 8G, using li
On Jan 23, 2018, at 2:49 PM, Mark H Weaver wrote:
>
> Joerg Schilling writes:
>
>> Mark H Weaver wrote:
>>
Now many bytes have been written past the hole?
>>>
>>> Did you read my entire message? The answer to your question was just a
>>> few lines beyond the excerpt that you quoted abo
On Jan 23, 2018, at 1:44 AM, Mark H Weaver wrote:
> Andreas Dilger writes:
>
>> On Jan 20, 2018, at 5:06 PM, Mark H Weaver wrote:
>>> Yes, on Btrfs I reliably see (st_blocks == 0) on a recently written,
>>> mostly sparse file with size > 8G, using linux-libre-4.14.14. More
>>> specifically, th
Joerg Schilling writes:
> Mark H Weaver wrote:
>
>> > Now many bytes have been written past the hole?
>>
>> Did you read my entire message? The answer to your question was just a
>> few lines beyond the excerpt that you quoted above. I wrote:
>>
>> >> Yes, on Btrfs I reliably see (st_blocks ==
Mark H Weaver wrote:
> > Now many bytes have been written past the hole?
>
> Did you read my entire message? The answer to your question was just a
> few lines beyond the excerpt that you quoted above. I wrote:
>
> >> Yes, on Btrfs I reliably see (st_blocks == 0) on a recently written,
> >> mos
Hi Andreas,
Andreas Dilger writes:
> On Jan 20, 2018, at 5:06 PM, Mark H Weaver wrote:
>> Yes, on Btrfs I reliably see (st_blocks == 0) on a recently written,
>> mostly sparse file with size > 8G, using linux-libre-4.14.14. More
>> specifically, the "storing sparse files > 8G" test in tar's te
Joerg Schilling writes:
> Mark H Weaver wrote:
>
>> Yes, on Btrfs I reliably see (st_blocks == 0) on a recently written,
>> mostly sparse file with size > 8G, using linux-libre-4.14.14. More
>> specifically, the "storing sparse files > 8G" test in tar's test suite
>> reliably fails on my system
On Jan 20, 2018, at 5:06 PM, Mark H Weaver wrote:
>
> Andreas Dilger writes:
>
>> On Jan 10, 2018, at 4:50 AM, Pavel Raiskup wrote:
>>>
>>> On Wednesday, January 10, 2018 3:42:52 AM CET Mark H Weaver wrote:
From da922703282b0d3b8837a99a9c7fdd32f1d20d49 Mon Sep 17 00:00:00 2001
From:
Mark H Weaver wrote:
> Yes, on Btrfs I reliably see (st_blocks == 0) on a recently written,
> mostly sparse file with size > 8G, using linux-libre-4.14.14. More
> specifically, the "storing sparse files > 8G" test in tar's test suite
> reliably fails on my system:
Now many bytes have been writt
Hi Andreas,
Andreas Dilger writes:
> On Jan 10, 2018, at 4:50 AM, Pavel Raiskup wrote:
>>
>> On Wednesday, January 10, 2018 3:42:52 AM CET Mark H Weaver wrote:
>>> From da922703282b0d3b8837a99a9c7fdd32f1d20d49 Mon Sep 17 00:00:00 2001
>>> From: Mark H Weaver
>>> Date: Tue, 9 Jan 2018 20:16:14
Andreas Dilger wrote:
> I'd be happy to have a proper SEEK_HOLE/SEEK_DATA implementation for
> Lustre, though it would be a bit tricky for sparse files striped over
> multiple OSTs. Probably the best way to handle this would be to
> fetch the FIEMAP data for each stripe to the client, and then i
On Jan 10, 2018, at 5:05 AM, Dominique Martinet
wrote:
>
> Hi,
>
> Pavel Raiskup wrote on Wed, Jan 10, 2018 at 12:50:06PM +0100:
>>> This check benefitted only one unlikely case (large files containing
>>> only zeroes, on systems that do not support SEEK_HOLE)
>>
>> It drops the optimization e
Andreas Dilger wrote:
> That means SEEK_HOLE is NOT available in RHEL 6.x kernels, which are still
> in fairly widespread (though declining) use. I'd prefer that the heuristic
> for sparse files without SEEK_HOLE not be removed completely, but I do think
> that it needs to be fixed for the small
On Jan 10, 2018, at 4:50 AM, Pavel Raiskup wrote:
>
> On Wednesday, January 10, 2018 3:42:52 AM CET Mark H Weaver wrote:
>> From da922703282b0d3b8837a99a9c7fdd32f1d20d49 Mon Sep 17 00:00:00 2001
>> From: Mark H Weaver
>> Date: Tue, 9 Jan 2018 20:16:14 -0500
>> Subject: [PATCH] Remove nonportable
Dominique Martinet wrote:
> Jumping in for lustre, for which there currently is a trivial SEEK_HOLE
> implementation that only checks file size boundaries, but I'd like to
> properly implement it soonish so I don't think tar should wait for
> lustre there.
> (not sure how Andreas feels about that
Hi,
Pavel Raiskup wrote on Wed, Jan 10, 2018 at 12:50:06PM +0100:
> > This check benefitted only one unlikely case (large files containing
> > only zeroes, on systems that do not support SEEK_HOLE)
>
> It drops the optimization even for situations when SEEK_HOLE is not
> available, which is not 1
On Wednesday, January 10, 2018 3:42:52 AM CET Mark H Weaver wrote:
> From da922703282b0d3b8837a99a9c7fdd32f1d20d49 Mon Sep 17 00:00:00 2001
> From: Mark H Weaver
> Date: Tue, 9 Jan 2018 20:16:14 -0500
> Subject: [PATCH] Remove nonportable check for files containing only zeroes.
>
> This check ben
Thanks, that patch looks reasonable to me. What do you think, Sergey?
>From da922703282b0d3b8837a99a9c7fdd32f1d20d49 Mon Sep 17 00:00:00 2001
From: Mark H Weaver
Date: Tue, 9 Jan 2018 20:16:14 -0500
Subject: [PATCH] Remove nonportable check for files containing only zeroes.
This check benefitted only one unlikely case (large files containing
only zeroes, on systems
21 matches
Mail list logo
