Re: New messages in OSD logs.

[Abhishek Lekshmanan <abhishek@suse.com>]

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