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@xxxxxxxxxxx> 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@xxxxxxxxxxx> >>> À: "Ceph Development" <ceph-devel@xxxxxxxxxxxxxxx> >>> 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@xxxxxxxxxxxxxxx >>> 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@xxxxxxxxxxxxxxx >>> 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@xxxxxxxxxxxxxxx >> 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
