On Thu, Mar 29, 2018 at 7:55 PM, Jayashree Mohan
wrote:
> Hi Filipe,
>
> I tried running the xfstest above on kernel 4.15.0 and I haven't been
> able to hit the bug. The xfstest passes clean for me. I compared the
> btrfs-debug-tree in my case with the one attached by
Hi Filipe,
I tried running the xfstest above on kernel 4.15.0 and I haven't been
able to hit the bug. The xfstest passes clean for me. I compared the
btrfs-debug-tree in my case with the one attached by Eryu, and I see I
do not have any xattr as he does. However, for every run of the
xfstest, the
On Wed, Mar 28, 2018 at 11:33 AM, Eryu Guan wrote:
> On Wed, Mar 28, 2018 at 09:48:17AM +0100, Filipe Manana wrote:
>> On Wed, Mar 28, 2018 at 3:17 AM, Eryu Guan wrote:
>> > On Mon, Mar 26, 2018 at 11:59:21PM +0100, fdman...@kernel.org wrote:
>> >> From:
On Wed, Mar 28, 2018 at 09:48:17AM +0100, Filipe Manana wrote:
> On Wed, Mar 28, 2018 at 3:17 AM, Eryu Guan wrote:
> > On Mon, Mar 26, 2018 at 11:59:21PM +0100, fdman...@kernel.org wrote:
> >> From: Filipe Manana
> >>
> >> Test that when we have the
On Wed, Mar 28, 2018 at 3:17 AM, Eryu Guan wrote:
> On Mon, Mar 26, 2018 at 11:59:21PM +0100, fdman...@kernel.org wrote:
>> From: Filipe Manana
>>
>> Test that when we have the no-holes mode enabled and a specific metadata
>> layout, if we punch a hole and
On Mon, Mar 26, 2018 at 11:59:21PM +0100, fdman...@kernel.org wrote:
> From: Filipe Manana
>
> Test that when we have the no-holes mode enabled and a specific metadata
> layout, if we punch a hole and fsync the file, at replay time the whole
> hole was preserved.
>
> This
From: Filipe Manana
Test that when we have the no-holes mode enabled and a specific metadata
layout, if we punch a hole and fsync the file, at replay time the whole
hole was preserved.
This issue is fixed by the following btrfs patch for the linux kernel:
"Btrfs: fix fsync