New messages in OSD logs.

New messages in OSD logs.

[Willem Jan Withagen]

Hi

I've recently rebased my fork, and also upgrae FreeBSD to more recent code.
Now I'm running into this:

2016-04-16 03:03:55.891466 805617000 -1
filestore(testdir/test-erasure-eio/0) WARNING: max attr value size (1024)
is smaller than osd_max_object_name_len (2048). Your backend filesystem
appears to not support attrs large enough
to handle the configured max rados name size. You may get unexpected
ENAMETOOLONG errors on rados operations or buggy behavior

and later on:

2016-04-16 03:04:03.287073 805617000  2 osd.0 0 boot
2016-04-16 03:04:03.287846 805617000 -1 osd.0 0 backend (filestore) is 
unable to support max object name[space] le
n
2016-04-16 03:04:03.287873 805617000 -1 osd.0 0    osd max object name 
len = 2048
2016-04-16 03:04:03.287894 805617000 -1 osd.0 0    osd max object 
namespace len = 256
2016-04-16 03:04:03.287931 805617000 -1 osd.0 0 (63) File name too long
2016-04-16 03:04:03.303432 805617000  1 journal close 
testdir/test-erasure-eio/0/journal
2016-04-16 03:04:03.310280 805617000 -1 ^[[0;31m ** ERROR: osd init 
failed: (63) File name too long^[[0m

And the OSD dies....

I guess that this has the do with the changes in the LFN modules, and is 
also the reason for the debate about ext4 support.

Uptill now unittest_chain_xattr did work, but that now also fails.
But it fails in a strange way where it tries to delete attributes with 
numerical ends that are certainly not in the attributes.
Maximum xattr name length in FreeBSD seems to be 256 chars, which wasn't 
a problem yet.

So is there any chance of continuing on my "old" way to finish a first 
version of the port?

Or am I just seeing things, and should I start looking at the FreeBSD 
side of things?


Thanx,
--WjW

Re: New messages in OSD logs.

[Gregory Farnum]

On Sat, Apr 16, 2016 at 4:07 AM, Willem Jan Withagen <wjw@digiware.nl> wrote:
> Hi
>
> I've recently rebased my fork, and also upgrae FreeBSD to more recent code.
> Now I'm running into this:
>
> 2016-04-16 03:03:55.891466 805617000 -1
> filestore(testdir/test-erasure-eio/0) WARNING: max attr value size (1024)
> is smaller than osd_max_object_name_len (2048). Your backend filesystem
> appears to not support attrs large enough
> to handle the configured max rados name size. You may get unexpected
> ENAMETOOLONG errors on rados operations or buggy behavior
>
> and later on:
>
> 2016-04-16 03:04:03.287073 805617000  2 osd.0 0 boot
> 2016-04-16 03:04:03.287846 805617000 -1 osd.0 0 backend (filestore) is
> unable to support max object name[space] le
> n
> 2016-04-16 03:04:03.287873 805617000 -1 osd.0 0    osd max object name len =
> 2048
> 2016-04-16 03:04:03.287894 805617000 -1 osd.0 0    osd max object namespace
> len = 256
> 2016-04-16 03:04:03.287931 805617000 -1 osd.0 0 (63) File name too long
> 2016-04-16 03:04:03.303432 805617000  1 journal close
> testdir/test-erasure-eio/0/journal
> 2016-04-16 03:04:03.310280 805617000 -1 ^[[0;31m ** ERROR: osd init failed:
> (63) File name too long^[[0m
>
> And the OSD dies....
>
> I guess that this has the do with the changes in the LFN modules, and is
> also the reason for the debate about ext4 support.
>
> Uptill now unittest_chain_xattr did work, but that now also fails.
> But it fails in a strange way where it tries to delete attributes with
> numerical ends that are certainly not in the attributes.
> Maximum xattr name length in FreeBSD seems to be 256 chars, which wasn't a
> problem yet.
>
> So is there any chance of continuing on my "old" way to finish a first
> version of the port?
>
> Or am I just seeing things, and should I start looking at the FreeBSD side
> of things?

I didn't do this work, but I think you should be able to set
osd_max_object_name_len and get things going. (I'm less sure about the
unit test.)
-Greg

Re: New messages in OSD logs.

[Erwan Velu]

I have the exact same trace while running a test on teuthology.

----- Mail original -----
De: "Willem Jan Withagen" <wjw@digiware.nl>
À: "Ceph Development" <ceph-devel@vger.kernel.org>
Envoyé: Samedi 16 Avril 2016 13:07:10
Objet: New messages in OSD logs.

Hi

I've recently rebased my fork, and also upgrae FreeBSD to more recent code.
Now I'm running into this:

2016-04-16 03:03:55.891466 805617000 -1
filestore(testdir/test-erasure-eio/0) WARNING: max attr value size (1024)
is smaller than osd_max_object_name_len (2048). Your backend filesystem
appears to not support attrs large enough
to handle the configured max rados name size. You may get unexpected
ENAMETOOLONG errors on rados operations or buggy behavior

and later on:

2016-04-16 03:04:03.287073 805617000  2 osd.0 0 boot
2016-04-16 03:04:03.287846 805617000 -1 osd.0 0 backend (filestore) is 
unable to support max object name[space] le
n
2016-04-16 03:04:03.287873 805617000 -1 osd.0 0    osd max object name 
len = 2048
2016-04-16 03:04:03.287894 805617000 -1 osd.0 0    osd max object 
namespace len = 256
2016-04-16 03:04:03.287931 805617000 -1 osd.0 0 (63) File name too long
2016-04-16 03:04:03.303432 805617000  1 journal close 
testdir/test-erasure-eio/0/journal
2016-04-16 03:04:03.310280 805617000 -1 ^[[0;31m ** ERROR: osd init 
failed: (63) File name too long^[[0m

And the OSD dies....

I guess that this has the do with the changes in the LFN modules, and is 
also the reason for the debate about ext4 support.

Uptill now unittest_chain_xattr did work, but that now also fails.
But it fails in a strange way where it tries to delete attributes with 
numerical ends that are certainly not in the attributes.
Maximum xattr name length in FreeBSD seems to be 256 chars, which wasn't 
a problem yet.

So is there any chance of continuing on my "old" way to finish a first 
version of the port?

Or am I just seeing things, and should I start looking at the FreeBSD 
side of things?


Thanx,
--WjW
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: New messages in OSD logs.

[Willem Jan Withagen]

On 20-4-2016 10:47, Erwan Velu wrote:
> I have the exact same trace while running a test on teuthology.

And I guess you are not running FreeBSD... :)
Teuthology would certainly not.


Does you test also ends in error?

--WjW

> ----- Mail original -----
> De: "Willem Jan Withagen" <wjw@digiware.nl>
> À: "Ceph Development" <ceph-devel@vger.kernel.org>
> Envoyé: Samedi 16 Avril 2016 13:07:10
> Objet: New messages in OSD logs.
> 
> Hi
> 
> I've recently rebased my fork, and also upgrae FreeBSD to more recent code.
> Now I'm running into this:
> 
> 2016-04-16 03:03:55.891466 805617000 -1
> filestore(testdir/test-erasure-eio/0) WARNING: max attr value size (1024)
> is smaller than osd_max_object_name_len (2048). Your backend filesystem
> appears to not support attrs large enough
> to handle the configured max rados name size. You may get unexpected
> ENAMETOOLONG errors on rados operations or buggy behavior
> 
> and later on:
> 
> 2016-04-16 03:04:03.287073 805617000  2 osd.0 0 boot
> 2016-04-16 03:04:03.287846 805617000 -1 osd.0 0 backend (filestore) is 
> unable to support max object name[space] le
> n
> 2016-04-16 03:04:03.287873 805617000 -1 osd.0 0    osd max object name 
> len = 2048
> 2016-04-16 03:04:03.287894 805617000 -1 osd.0 0    osd max object 
> namespace len = 256
> 2016-04-16 03:04:03.287931 805617000 -1 osd.0 0 (63) File name too long
> 2016-04-16 03:04:03.303432 805617000  1 journal close 
> testdir/test-erasure-eio/0/journal
> 2016-04-16 03:04:03.310280 805617000 -1 ^[[0;31m ** ERROR: osd init 
> failed: (63) File name too long^[[0m
> 
> And the OSD dies....
> 
> I guess that this has the do with the changes in the LFN modules, and is 
> also the reason for the debate about ext4 support.
> 
> Uptill now unittest_chain_xattr did work, but that now also fails.
> But it fails in a strange way where it tries to delete attributes with 
> numerical ends that are certainly not in the attributes.
> Maximum xattr name length in FreeBSD seems to be 256 chars, which wasn't 
> a problem yet.
> 
> So is there any chance of continuing on my "old" way to finish a first 
> version of the port?
> 
> Or am I just seeing things, and should I start looking at the FreeBSD 
> side of things?
> 
> 
> Thanx,
> --WjW
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: New messages in OSD logs.

[Alyona Kiselyova]

Hi,
I have the same error on last master and my rebased forks, when try to
use vstart or start any test (on Ubuntu). Change of
osd_max_object_name_len remove warning, but osds are still dying. So,
I cannot test anything on developer cluster since yesterday rebase.
Also I've rebased two PRs on the last master yesterday, and both have
all tests failed in check, like it happens on my machine. Today's
master didn't help)
-------------------------------
Best regards,
Alyona Kiseleva


On Wed, Apr 20, 2016 at 12:41 PM, Willem Jan Withagen <wjw@digiware.nl> wrote:
> On 20-4-2016 10:47, Erwan Velu wrote:
>> I have the exact same trace while running a test on teuthology.
>
> And I guess you are not running FreeBSD... :)
> Teuthology would certainly not.
>
>
> Does you test also ends in error?
>
> --WjW
>
>> ----- Mail original -----
>> De: "Willem Jan Withagen" <wjw@digiware.nl>
>> À: "Ceph Development" <ceph-devel@vger.kernel.org>
>> Envoyé: Samedi 16 Avril 2016 13:07:10
>> Objet: New messages in OSD logs.
>>
>> Hi
>>
>> I've recently rebased my fork, and also upgrae FreeBSD to more recent code.
>> Now I'm running into this:
>>
>> 2016-04-16 03:03:55.891466 805617000 -1
>> filestore(testdir/test-erasure-eio/0) WARNING: max attr value size (1024)
>> is smaller than osd_max_object_name_len (2048). Your backend filesystem
>> appears to not support attrs large enough
>> to handle the configured max rados name size. You may get unexpected
>> ENAMETOOLONG errors on rados operations or buggy behavior
>>
>> and later on:
>>
>> 2016-04-16 03:04:03.287073 805617000  2 osd.0 0 boot
>> 2016-04-16 03:04:03.287846 805617000 -1 osd.0 0 backend (filestore) is
>> unable to support max object name[space] le
>> n
>> 2016-04-16 03:04:03.287873 805617000 -1 osd.0 0    osd max object name
>> len = 2048
>> 2016-04-16 03:04:03.287894 805617000 -1 osd.0 0    osd max object
>> namespace len = 256
>> 2016-04-16 03:04:03.287931 805617000 -1 osd.0 0 (63) File name too long
>> 2016-04-16 03:04:03.303432 805617000  1 journal close
>> testdir/test-erasure-eio/0/journal
>> 2016-04-16 03:04:03.310280 805617000 -1 ^[[0;31m ** ERROR: osd init
>> failed: (63) File name too long^[[0m
>>
>> And the OSD dies....
>>
>> I guess that this has the do with the changes in the LFN modules, and is
>> also the reason for the debate about ext4 support.
>>
>> Uptill now unittest_chain_xattr did work, but that now also fails.
>> But it fails in a strange way where it tries to delete attributes with
>> numerical ends that are certainly not in the attributes.
>> Maximum xattr name length in FreeBSD seems to be 256 chars, which wasn't
>> a problem yet.
>>
>> So is there any chance of continuing on my "old" way to finish a first
>> version of the port?
>>
>> Or am I just seeing things, and should I start looking at the FreeBSD
>> side of things?
>>
>>
>> Thanx,
>> --WjW
>> --
>> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> --
>> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: New messages in OSD logs.

[Abhishek Lekshmanan]

Alyona Kiselyova writes:

> Hi,
> I have the same error on last master and my rebased forks, when try to
> use vstart or start any test (on Ubuntu). Change of
> osd_max_object_name_len remove warning, but osds are still dying. So,
> I cannot test anything on developer cluster since yesterday rebase.
> Also I've rebased two PRs on the last master yesterday, and both have
> all tests failed in check, like it happens on my machine. Today's
> master didn't help)

`--short` option in vstart worked for me for just running dev clusters
and such on ext4, though I haven't run the entire make check suite yet.

> -------------------------------
> Best regards,
> Alyona Kiseleva
>
>
> On Wed, Apr 20, 2016 at 12:41 PM, Willem Jan Withagen <wjw@digiware.nl> wrote:
>> On 20-4-2016 10:47, Erwan Velu wrote:
>>> I have the exact same trace while running a test on teuthology.
>>
>> And I guess you are not running FreeBSD... :)
>> Teuthology would certainly not.
>>
>>
>> Does you test also ends in error?
>>
>> --WjW
>>
>>> ----- Mail original -----
>>> De: "Willem Jan Withagen" <wjw@digiware.nl>
>>> À: "Ceph Development" <ceph-devel@vger.kernel.org>
>>> Envoyé: Samedi 16 Avril 2016 13:07:10
>>> Objet: New messages in OSD logs.
>>>
>>> Hi
>>>
>>> I've recently rebased my fork, and also upgrae FreeBSD to more recent code.
>>> Now I'm running into this:
>>>
>>> 2016-04-16 03:03:55.891466 805617000 -1
>>> filestore(testdir/test-erasure-eio/0) WARNING: max attr value size (1024)
>>> is smaller than osd_max_object_name_len (2048). Your backend filesystem
>>> appears to not support attrs large enough
>>> to handle the configured max rados name size. You may get unexpected
>>> ENAMETOOLONG errors on rados operations or buggy behavior
>>>
>>> and later on:
>>>
>>> 2016-04-16 03:04:03.287073 805617000  2 osd.0 0 boot
>>> 2016-04-16 03:04:03.287846 805617000 -1 osd.0 0 backend (filestore) is
>>> unable to support max object name[space] le
>>> n
>>> 2016-04-16 03:04:03.287873 805617000 -1 osd.0 0    osd max object name
>>> len = 2048
>>> 2016-04-16 03:04:03.287894 805617000 -1 osd.0 0    osd max object
>>> namespace len = 256
>>> 2016-04-16 03:04:03.287931 805617000 -1 osd.0 0 (63) File name too long
>>> 2016-04-16 03:04:03.303432 805617000  1 journal close
>>> testdir/test-erasure-eio/0/journal
>>> 2016-04-16 03:04:03.310280 805617000 -1 ^[[0;31m ** ERROR: osd init
>>> failed: (63) File name too long^[[0m
>>>
>>> And the OSD dies....
>>>
>>> I guess that this has the do with the changes in the LFN modules, and is
>>> also the reason for the debate about ext4 support.
>>>
>>> Uptill now unittest_chain_xattr did work, but that now also fails.
>>> But it fails in a strange way where it tries to delete attributes with
>>> numerical ends that are certainly not in the attributes.
>>> Maximum xattr name length in FreeBSD seems to be 256 chars, which wasn't
>>> a problem yet.
>>>
>>> So is there any chance of continuing on my "old" way to finish a first
>>> version of the port?
>>>
>>> Or am I just seeing things, and should I start looking at the FreeBSD
>>> side of things?
>>>
>>>
>>> Thanx,
>>> --WjW
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html


--
Abhishek Lekshmanan
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: New messages in OSD logs.

[Willem Jan Withagen]

On 18-4-2016 20:52, Gregory Farnum wrote:
> On Sat, Apr 16, 2016 at 4:07 AM, Willem Jan Withagen <wjw@digiware.nl> wrote:
>> Hi
>>
>> I've recently rebased my fork, and also upgrae FreeBSD to more recent code.
>> Now I'm running into this:
>>
>> 2016-04-16 03:03:55.891466 805617000 -1
>> filestore(testdir/test-erasure-eio/0) WARNING: max attr value size (1024)
>> is smaller than osd_max_object_name_len (2048). Your backend filesystem
>> appears to not support attrs large enough
>> to handle the configured max rados name size. You may get unexpected
>> ENAMETOOLONG errors on rados operations or buggy behavior
>>
>> and later on:
>>
>> 2016-04-16 03:04:03.287073 805617000  2 osd.0 0 boot
>> 2016-04-16 03:04:03.287846 805617000 -1 osd.0 0 backend (filestore) is
>> unable to support max object name[space] le
>> n
>> 2016-04-16 03:04:03.287873 805617000 -1 osd.0 0    osd max object name len =
>> 2048
>> 2016-04-16 03:04:03.287894 805617000 -1 osd.0 0    osd max object namespace
>> len = 256
>> 2016-04-16 03:04:03.287931 805617000 -1 osd.0 0 (63) File name too long
>> 2016-04-16 03:04:03.303432 805617000  1 journal close
>> testdir/test-erasure-eio/0/journal
>> 2016-04-16 03:04:03.310280 805617000 -1 ^[[0;31m ** ERROR: osd init failed:
>> (63) File name too long^[[0m
>>
>> And the OSD dies....
>>
>> I guess that this has the do with the changes in the LFN modules, and is
>> also the reason for the debate about ext4 support.
>>
>> Uptill now unittest_chain_xattr did work, but that now also fails.
>> But it fails in a strange way where it tries to delete attributes with
>> numerical ends that are certainly not in the attributes.
>> Maximum xattr name length in FreeBSD seems to be 256 chars, which wasn't a
>> problem yet.
>>
>> So is there any chance of continuing on my "old" way to finish a first
>> version of the port?
>>
>> Or am I just seeing things, and should I start looking at the FreeBSD side
>> of things?
> 
> I didn't do this work, but I think you should be able to set
> osd_max_object_name_len and get things going. (I'm less sure about the
> unit test.)

Hi,

Wierd things are happening here as far as I can tell....

linux/limits.h defines:
#define XATTR_NAME_MAX   255 /* # chars in an extended attribute name */
#define XATTR_SIZE_MAX 65536 /* size of an extended attribute value (64k) */
#define XATTR_LIST_MAX 65536 /* size of extended attribute namelist (64k) */

Which is exactly the same as is on FreeBSD:
max namesize is 255 chars, content of attributes max 64K

Even wrote some perl to actually test this. And it is true.

So I'm not really understanding why the OSDs are complaining and dying
on the basis of this. Linux OSDs should have the same problem... :(

--WjW

Re: New messages in OSD logs.

[Gregory Farnum]

On Fri, Apr 22, 2016 at 8:55 AM, Willem Jan Withagen <wjw@digiware.nl> wrote:
> On 18-4-2016 20:52, Gregory Farnum wrote:
>> On Sat, Apr 16, 2016 at 4:07 AM, Willem Jan Withagen <wjw@digiware.nl> wrote:
>>> Hi
>>>
>>> I've recently rebased my fork, and also upgrae FreeBSD to more recent code.
>>> Now I'm running into this:
>>>
>>> 2016-04-16 03:03:55.891466 805617000 -1
>>> filestore(testdir/test-erasure-eio/0) WARNING: max attr value size (1024)
>>> is smaller than osd_max_object_name_len (2048). Your backend filesystem
>>> appears to not support attrs large enough
>>> to handle the configured max rados name size. You may get unexpected
>>> ENAMETOOLONG errors on rados operations or buggy behavior
>>>
>>> and later on:
>>>
>>> 2016-04-16 03:04:03.287073 805617000  2 osd.0 0 boot
>>> 2016-04-16 03:04:03.287846 805617000 -1 osd.0 0 backend (filestore) is
>>> unable to support max object name[space] le
>>> n
>>> 2016-04-16 03:04:03.287873 805617000 -1 osd.0 0    osd max object name len =
>>> 2048
>>> 2016-04-16 03:04:03.287894 805617000 -1 osd.0 0    osd max object namespace
>>> len = 256
>>> 2016-04-16 03:04:03.287931 805617000 -1 osd.0 0 (63) File name too long
>>> 2016-04-16 03:04:03.303432 805617000  1 journal close
>>> testdir/test-erasure-eio/0/journal
>>> 2016-04-16 03:04:03.310280 805617000 -1 ^[[0;31m ** ERROR: osd init failed:
>>> (63) File name too long^[[0m
>>>
>>> And the OSD dies....
>>>
>>> I guess that this has the do with the changes in the LFN modules, and is
>>> also the reason for the debate about ext4 support.
>>>
>>> Uptill now unittest_chain_xattr did work, but that now also fails.
>>> But it fails in a strange way where it tries to delete attributes with
>>> numerical ends that are certainly not in the attributes.
>>> Maximum xattr name length in FreeBSD seems to be 256 chars, which wasn't a
>>> problem yet.
>>>
>>> So is there any chance of continuing on my "old" way to finish a first
>>> version of the port?
>>>
>>> Or am I just seeing things, and should I start looking at the FreeBSD side
>>> of things?
>>
>> I didn't do this work, but I think you should be able to set
>> osd_max_object_name_len and get things going. (I'm less sure about the
>> unit test.)
>
> Hi,
>
> Wierd things are happening here as far as I can tell....
>
> linux/limits.h defines:
> #define XATTR_NAME_MAX   255 /* # chars in an extended attribute name */
> #define XATTR_SIZE_MAX 65536 /* size of an extended attribute value (64k) */
> #define XATTR_LIST_MAX 65536 /* size of extended attribute namelist (64k) */
>
> Which is exactly the same as is on FreeBSD:
> max namesize is 255 chars, content of attributes max 64K
>
> Even wrote some perl to actually test this. And it is true.

Hmm, it's possible the Linux VFS and some FSes may grant more leniency
about letting through long xattr names.

Like I said, if you check the patches responsible for these warnings
you should be able to find the right config settings to bypass the
problem.
-Greg

Re: New messages in OSD logs.

[Willem Jan Withagen]

On 22-4-2016 17:10, Gregory Farnum wrote:
> On Fri, Apr 22, 2016 at 8:55 AM, Willem Jan Withagen <wjw@digiware.nl> wrote:
>> On 18-4-2016 20:52, Gregory Farnum wrote:
>>> On Sat, Apr 16, 2016 at 4:07 AM, Willem Jan Withagen <wjw@digiware.nl> wrote:
>>>> Hi
>>>>
>>>> I've recently rebased my fork, and also upgrae FreeBSD to more recent code.
>>>> Now I'm running into this:
>>>>
>>>> 2016-04-16 03:03:55.891466 805617000 -1
>>>> filestore(testdir/test-erasure-eio/0) WARNING: max attr value size (1024)
>>>> is smaller than osd_max_object_name_len (2048). Your backend filesystem
>>>> appears to not support attrs large enough
>>>> to handle the configured max rados name size. You may get unexpected
>>>> ENAMETOOLONG errors on rados operations or buggy behavior
>>>>
>>>> and later on:
>>>>
>>>> 2016-04-16 03:04:03.287073 805617000  2 osd.0 0 boot
>>>> 2016-04-16 03:04:03.287846 805617000 -1 osd.0 0 backend (filestore) is
>>>> unable to support max object name[space] le
>>>> n
>>>> 2016-04-16 03:04:03.287873 805617000 -1 osd.0 0    osd max object name len =
>>>> 2048
>>>> 2016-04-16 03:04:03.287894 805617000 -1 osd.0 0    osd max object namespace
>>>> len = 256
>>>> 2016-04-16 03:04:03.287931 805617000 -1 osd.0 0 (63) File name too long
>>>> 2016-04-16 03:04:03.303432 805617000  1 journal close
>>>> testdir/test-erasure-eio/0/journal
>>>> 2016-04-16 03:04:03.310280 805617000 -1 ^[[0;31m ** ERROR: osd init failed:
>>>> (63) File name too long^[[0m
>>>>
>>>> And the OSD dies....
>>>>
>>>> I guess that this has the do with the changes in the LFN modules, and is
>>>> also the reason for the debate about ext4 support.
>>>>
>>>> Uptill now unittest_chain_xattr did work, but that now also fails.
>>>> But it fails in a strange way where it tries to delete attributes with
>>>> numerical ends that are certainly not in the attributes.
>>>> Maximum xattr name length in FreeBSD seems to be 256 chars, which wasn't a
>>>> problem yet.
>>>>
>>>> So is there any chance of continuing on my "old" way to finish a first
>>>> version of the port?
>>>>
>>>> Or am I just seeing things, and should I start looking at the FreeBSD side
>>>> of things?
>>>
>>> I didn't do this work, but I think you should be able to set
>>> osd_max_object_name_len and get things going. (I'm less sure about the
>>> unit test.)
>>
>> Hi,
>>
>> Wierd things are happening here as far as I can tell....
>>
>> linux/limits.h defines:
>> #define XATTR_NAME_MAX   255 /* # chars in an extended attribute name */
>> #define XATTR_SIZE_MAX 65536 /* size of an extended attribute value (64k) */
>> #define XATTR_LIST_MAX 65536 /* size of extended attribute namelist (64k) */
>>
>> Which is exactly the same as is on FreeBSD:
>> max namesize is 255 chars, content of attributes max 64K
>>
>> Even wrote some perl to actually test this. And it is true.
>
> Hmm, it's possible the Linux VFS and some FSes may grant more leniency
> about letting through long xattr names.
>
> Like I said, if you check the patches responsible for these warnings
> you should be able to find the right config settings to bypass the
> problem.

Hi Greg,

I'll do some more testing in my CentOS/xfs box to see where that ends.

Sofar it is a no go, when running OSDs, but I think I just found the catch.
Seemed that FreeBSD returns ENOATTR if the name is not found. And Ceph 
tests on
ENODATA. That should error during compilation because ENODATA is unknown 
in FreeBSD.

The unitest_chain_xattr completes again, but I still have to integrate 
the code that
accepts the fact that the order of attributes is not fixed(in FreeBSD).

In the mean time I also found:
/*
  * chaining xattrs
  *
  * In order to support xattrs that are larger than the xattr size limit 
that some file systems
  * impose, we use multiple xattrs to store the value of a single xattr. 
The xattrs keys
  * are set as follows:
  * The first xattr in the chain, has a key that holds the original 
xattr name, with any '@' char
  * being esacped ("@@").
  * The chained keys will have the first xattr's key (with the 
escaping), and a suffix: "@<id>"
  * where <id> marks the num of xattr in the chain.
  */

And I interpret this as the CONTENT of the attribute is going to be 
chained over multipe attributes.
Could be that this is more than obvious for native speakers, but needed 
some rereading and code to
extract the full meaning. So if naything needs to change here, I'll try 
to extent it with some 'content'
sprinkels.

--WjW