Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 10 Jan 2016 19:07:34 +0100
From:      Willem Jan Withagen <wjw@digiware.nl>
To:        Ian Lepore <ian@freebsd.org>, freebsd-hackers@freebsd.org
Subject:   Re: Attribute order in storing and retreiving extended attributes
Message-ID:  <56929DE6.4040308@digiware.nl>
In-Reply-To: <1452447979.1523.11.camel@freebsd.org>
References:  <56928D06.4050500@digiware.nl> <1452447979.1523.11.camel@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On 10-1-2016 18:46, Ian Lepore wrote:
> On Sun, 2016-01-10 at 17:55 +0100, Willem Jan Withagen wrote:
>> Hi,
>>
>> I'm looking into why a snippet of Ceph testcode sometimes retuns
>> error,
>> and other times does complete oke.
>>
>> It seems that under Linux the way order of attributes is always
>> consistent in the same order.
>>
>> Where as on FreeBSD it can happen that even with the same sequence of
>> extattr_set_* will give a different order in the extattr_list_fd
>> output.
>> And because the outputbuffer is compared with memcmp an error is
>> detected.
>>
>> Easy to verify with lsextattr, which also gives a different order.
>>
>> When things go oke the order is:
>> # lsextattr user chain_xattr_listxatrr
>> chain_xattr_listxatrr, size: 512
>> user.1111111111111111111111111111111111111111111111111111111111111111
>> 111
>> 11111111111111111111111111111111111111111111111111111111@1
>> user.1111111111111111111111111111111111111111111111111111111111111111
>> 111
>> 11111111111111111111111111111111111111111111111111111111
>> user.@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
>> @@@
>> @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
>> @@@
>> @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
>> @@@
>> @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
>>
>> When thing go wrong, the order is:
>>  # lsextattr user chain_xattr_listxatrr
>> chain_xattr_listxatrr, size: 512
>> user.1111111111111111111111111111111111111111111111111111111111111111
>> 111
>> 11111111111111111111111111111111111111111111111111111111
>> user.1111111111111111111111111111111111111111111111111111111111111111
>> 111
>> 11111111111111111111111111111111111111111111111111111111@1
>> user.@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
>> @@@
>> @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
>> @@@
>> @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
>> @@@
>> @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
>>
>> This is on a ZFS filesystem.
>> Is there any particular reason why these is not deterministic?
>> I do not have a testbox with UFS available, so it is hard to verify
>> that
>> it occurs there too.
>>
>> Would this be easy to make more deterministic?
>>
> 
> Could you just pipe the lsextattr output through sort to make it
> deterministic?
Hi Ian,

I'm just using lsextattr as a means of showing what is going on.
In the Ceph code there is the expectancy that the attributes are
returned in the same order the attributes are inserted.
So for the time being I disabled the test, and perhaps I'm going to
rewrite it into explicit test for the inserted attributes.

--WjW





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?56929DE6.4040308>