On Wed, Mar 28, 2018 at 11:33 AM, Eryu Guan <guane...@gmail.com> 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 <guane...@gmail.com> wrote:
>> > On Mon, Mar 26, 2018 at 11:59:21PM +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"
>> >
>> > I'd expect a test failure with 4.16-rc6 kernel, as the mentioned fix
>> > above is not there. But test always passes for me. Did I miss anything?
>> > btrfs-progs version is btrfs-progs-4.11.1-3.fc27.
>>
>> It should fail on any kernel, with any btrfs-progs version (which
>> should be irrelevant).
>> Somehow on your system we are not getting the specific metadata layout
>> needed to trigger the issue.
>>
>> Can you apply the following patch on top of the test and provide the
>> result 159.full file?
>>
>> https://friendpaste.com/6xAuLeN4xl1AGjO9Qc5I8L
>>
>> So that I can see what metadata layout you are getting.
>> Thanks!
>
> Sure, please see attachment.
Thanks!
So you indeed get a different metadata layout, and that is because you
have SELinux enabled which causes some xattr to be added to the test
file (foobar):
item 6 key (257 XATTR_ITEM 3817753667) itemoff 64932 itemsize 83
location key (0 UNKNOWN.0 0) type XATTR
transid 7 data_len 37 name_len 16
name: security.selinux
data unconfined_u:object_r:unlabeled_t:s0
I can make the test work with and without selinux enabled (by punching
holes on a few extents that are candidates to be at leaf boundaries).
Is it worth it? (I assume most people run the tests without selinux)
thanks
>
> Thanks,
> Eryu
--
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
