On Mon, Apr 9, 2018 at 2:05 PM, Eryu Guan <guane...@gmail.com> wrote:
> On Sun, Apr 08, 2018 at 09:46:24AM +0100, Filipe Manana wrote:
>> On Sun, Apr 8, 2018 at 8:46 AM, Eryu Guan <guane...@gmail.com> wrote:
>> > On Wed, Mar 28, 2018 at 12:55:30PM +0100, fdman...@kernel.org wrote:
>> >> From: Filipe Manana <fdman...@suse.com>
>> >> 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 after hole punching when using no-holes feature"
>> >> Signed-off-by: Filipe Manana <fdman...@suse.com>
>> >> ---
>> >> V2: Made the test work when selinux is enabled, and made it use direct IO
>> >> writes to ensure 256K extents.
>> > Test fails with selinux enabled now on unpatched kernel. But I found
>> > that, in my release testing, test still fails when testing with current
>> > Linus tree (HEAD is 642e7fd23353, without selinux this time), which
>> > should contain the mentioned fix. Does that mean the bug is not fully
>> > fixed?
>> The bug is fully fixed. But HEAD 642e7fd23353 does not contain the
>> fix. The current linus' master has it.
> I'll double check.. Thanks for the heads-up!
Hi Eryu, any reason this didn't go in the last update?
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html