It is not so easy.. When I added fsid under selected osd` section and reformatted the store/journal, it aborted at start in FileStore::_do_transaction (see attach). On next launch, fsid in the mon store for this OSD magically changes to the something else and I am kicking again same doorstep (if I shut down osd process, recreate journal with new fsid inserted in fsid or recreate entire filestore too, it will abort, otherwise simply not join due to *next* mismatch). As far as I can see problem is in behavior of legacy clusters which are inherited fsid from filesystem created by third-party, not as a result of ceph-deploy work, so it is not fixed at all after such an update. Any suggestions? Trace is attached if someone is interested in it. On Thu, Oct 23, 2014 at 5:25 PM, Andrey Korolyov <andrey@xxxxxxx> wrote: > Sorry, I see the problem. > > osd.0 10.6.0.1:6800/32051 clashes with existing osd: different fsid > (ours: d0aec02e-8513-40f1-bf34-22ec44f68466 ; theirs: > 16cbb1f8-e896-42cd-863c-bcbad710b4ea). Anyway it is clearly a bug and > fsid should be silently discarded there if OSD contains no epochs > itself.
Attachment:
abrt-at-start.txt.gz
Description: GNU Zip compressed data
_______________________________________________ ceph-users mailing list ceph-users@xxxxxxxxxxxxxx http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
