All of lore.kernel.org
 help / color / mirror / Atom feed
* mkcephfs regression in current master branch
@ 2012-05-24 19:39 Jim Schutt
  2012-05-24 21:13 ` Sage Weil
  0 siblings, 1 reply; 3+ messages in thread
From: Jim Schutt @ 2012-05-24 19:39 UTC (permalink / raw)
  To: ceph-devel@vger.kernel.org

Hi,

In my testing I make repeated use of the "manual" mkcephfs
sequence described in the man page:

    master# mkdir /tmp/foo
    master# mkcephfs -c /etc/ceph/ceph.conf --prepare-monmap -d /tmp/foo
    osdnode# mkcephfs --init-local-daemons osd -d /tmp/foo
    mdsnode# mkcephfs --init-local-daemons mds -d /tmp/foo
    master# mkcephfs --prepare-mon -d /tmp/foo
    monnode# mkcephfs --init-local-daemons mon -d /tmp/foo

Using current master branch (commit ca79f45a33f9), the
"mkcephfs --init-local-daemons osd" phase breaks like this:

2012-05-24 13:24:06.325905 7fdcd61d4780 -1 filestore(/ram/mnt/ceph/data.osd.0) could not find 23c2fcde/osd_superblock/0 in index: (2) No such file or directory
2012-05-24 13:24:06.326768 7fdcd1ee2700 -1 filestore(/ram/mnt/ceph/data.osd.0) async snap create 'snap_1' transid 0 got (17) File exists
os/FileStore.cc: In function 'void FileStore::sync_entry()' thread 7fdcd1ee2700 time 2012-05-24 13:24:06.326792
os/FileStore.cc: 3564: FAILED assert(0 == "async snap ioctl error")
  ceph version 0.47.1-157-gb003815 (commit:b003815c222add8bdcf645d9ba4ef7e13f34587e)
  1: (FileStore::sync_entry()+0x34f0) [0x68e190]
  2: (FileStore::SyncThread::entry()+0xd) [0x6a2abd]
  3: (Thread::_entry_func(void*)+0x1b9) [0x803499]
  4: (()+0x77f1) [0x7fdcd58637f1]
  5: (clone()+0x6d) [0x7fdcd4cb4ccd]
  NOTE: a copy of the executable, or `objdump -rdS <executable>` is needed to interpret this.
2012-05-24 13:24:06.327991 7fdcd1ee2700 -1 os/FileStore.cc: In function 'void FileStore::sync_entry()' thread 7fdcd1ee2700 time 2012-05-24 13:24:06.326792
os/FileStore.cc: 3564: FAILED assert(0 == "async snap ioctl error")

FWIW, with commit 598dea12411 (filestore: mkfs: only
create snap_0 if we created current_op_seq) reverted,
I am able to create a new filesystem using the above
sequence, and a typical "mkcephfs --init-local-daemons osd"
looks like this:

2012-05-24 13:06:25.918663 7fe7ac829780 -1 filestore(/ram/mnt/ceph/data.osd.0) could not find 23c2fcde/osd_superblock/0 in index: (2) No such file or directory
2012-05-24 13:06:26.301738 7fe7ac829780 -1 created object store /ram/mnt/ceph/data.osd.0 journal /dev/mapper/cs32s01p2 for osd.0 fsid f8cc9fa2-a300-45a1-ae6d-e0c0ef418d0f
creating private key for osd.0 keyring /mnt/ceph/misc.osd.0/keyring.osd.0
creating /mnt/ceph/misc.osd.0/keyring.osd.0

Thanks -- Jim


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: mkcephfs regression in current master branch
  2012-05-24 19:39 mkcephfs regression in current master branch Jim Schutt
@ 2012-05-24 21:13 ` Sage Weil
  2012-05-24 21:46   ` Jim Schutt
  0 siblings, 1 reply; 3+ messages in thread
From: Sage Weil @ 2012-05-24 21:13 UTC (permalink / raw)
  To: Jim Schutt; +Cc: ceph-devel@vger.kernel.org

Hi Jim,

On Thu, 24 May 2012, Jim Schutt wrote:

> Hi,
> 
> In my testing I make repeated use of the "manual" mkcephfs
> sequence described in the man page:
> 
>    master# mkdir /tmp/foo
>    master# mkcephfs -c /etc/ceph/ceph.conf --prepare-monmap -d /tmp/foo
>    osdnode# mkcephfs --init-local-daemons osd -d /tmp/foo
>    mdsnode# mkcephfs --init-local-daemons mds -d /tmp/foo
>    master# mkcephfs --prepare-mon -d /tmp/foo
>    monnode# mkcephfs --init-local-daemons mon -d /tmp/foo
> 
> Using current master branch (commit ca79f45a33f9), the
> "mkcephfs --init-local-daemons osd" phase breaks like this:
> 
> 2012-05-24 13:24:06.325905 7fdcd61d4780 -1 filestore(/ram/mnt/ceph/data.osd.0)
> could not find 23c2fcde/osd_superblock/0 in index: (2) No such file or
> directory
> 2012-05-24 13:24:06.326768 7fdcd1ee2700 -1 filestore(/ram/mnt/ceph/data.osd.0)
> async snap create 'snap_1' transid 0 got (17) File exists
> os/FileStore.cc: In function 'void FileStore::sync_entry()' thread
> 7fdcd1ee2700 time 2012-05-24 13:24:06.326792
> os/FileStore.cc: 3564: FAILED assert(0 == "async snap ioctl error")
>  ceph version 0.47.1-157-gb003815
> (commit:b003815c222add8bdcf645d9ba4ef7e13f34587e)
>  1: (FileStore::sync_entry()+0x34f0) [0x68e190]
>  2: (FileStore::SyncThread::entry()+0xd) [0x6a2abd]
>  3: (Thread::_entry_func(void*)+0x1b9) [0x803499]
>  4: (()+0x77f1) [0x7fdcd58637f1]
>  5: (clone()+0x6d) [0x7fdcd4cb4ccd]
>  NOTE: a copy of the executable, or `objdump -rdS <executable>` is needed to
> interpret this.
> 2012-05-24 13:24:06.327991 7fdcd1ee2700 -1 os/FileStore.cc: In function 'void
> FileStore::sync_entry()' thread 7fdcd1ee2700 time 2012-05-24 13:24:06.326792
> os/FileStore.cc: 3564: FAILED assert(0 == "async snap ioctl error")

I just pushed a fix for this to master.

BTW, the real change happening with these patches is that --mkfs no longer 
clobbers existing data.  If you want to wipe out an osd and start anew, 
you need to rm -r (and btrfs sub delete snap_* and current), or re-run 
mkfs.btrfs.

Thanks for the report!

sage



> 
> FWIW, with commit 598dea12411 (filestore: mkfs: only
> create snap_0 if we created current_op_seq) reverted,
> I am able to create a new filesystem using the above
> sequence, and a typical "mkcephfs --init-local-daemons osd"
> looks like this:
> 
> 2012-05-24 13:06:25.918663 7fe7ac829780 -1 filestore(/ram/mnt/ceph/data.osd.0)
> could not find 23c2fcde/osd_superblock/0 in index: (2) No such file or
> directory
> 2012-05-24 13:06:26.301738 7fe7ac829780 -1 created object store
> /ram/mnt/ceph/data.osd.0 journal /dev/mapper/cs32s01p2 for osd.0 fsid
> f8cc9fa2-a300-45a1-ae6d-e0c0ef418d0f
> creating private key for osd.0 keyring /mnt/ceph/misc.osd.0/keyring.osd.0
> creating /mnt/ceph/misc.osd.0/keyring.osd.0
> 
> Thanks -- Jim
> 
> --
> 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
> 
> 

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: mkcephfs regression in current master branch
  2012-05-24 21:13 ` Sage Weil
@ 2012-05-24 21:46   ` Jim Schutt
  0 siblings, 0 replies; 3+ messages in thread
From: Jim Schutt @ 2012-05-24 21:46 UTC (permalink / raw)
  To: Sage Weil; +Cc: ceph-devel@vger.kernel.org

On 05/24/2012 03:13 PM, Sage Weil wrote:
> Hi Jim,
>
> On Thu, 24 May 2012, Jim Schutt wrote:
>
>> Hi,
>>
>> In my testing I make repeated use of the "manual" mkcephfs
>> sequence described in the man page:
>>
>>     master# mkdir /tmp/foo
>>     master# mkcephfs -c /etc/ceph/ceph.conf --prepare-monmap -d /tmp/foo
>>     osdnode# mkcephfs --init-local-daemons osd -d /tmp/foo
>>     mdsnode# mkcephfs --init-local-daemons mds -d /tmp/foo
>>     master# mkcephfs --prepare-mon -d /tmp/foo
>>     monnode# mkcephfs --init-local-daemons mon -d /tmp/foo
>>
>> Using current master branch (commit ca79f45a33f9), the
>> "mkcephfs --init-local-daemons osd" phase breaks like this:
>>
>> 2012-05-24 13:24:06.325905 7fdcd61d4780 -1 filestore(/ram/mnt/ceph/data.osd.0)
>> could not find 23c2fcde/osd_superblock/0 in index: (2) No such file or
>> directory
>> 2012-05-24 13:24:06.326768 7fdcd1ee2700 -1 filestore(/ram/mnt/ceph/data.osd.0)
>> async snap create 'snap_1' transid 0 got (17) File exists
>> os/FileStore.cc: In function 'void FileStore::sync_entry()' thread
>> 7fdcd1ee2700 time 2012-05-24 13:24:06.326792
>> os/FileStore.cc: 3564: FAILED assert(0 == "async snap ioctl error")
>>   ceph version 0.47.1-157-gb003815
>> (commit:b003815c222add8bdcf645d9ba4ef7e13f34587e)
>>   1: (FileStore::sync_entry()+0x34f0) [0x68e190]
>>   2: (FileStore::SyncThread::entry()+0xd) [0x6a2abd]
>>   3: (Thread::_entry_func(void*)+0x1b9) [0x803499]
>>   4: (()+0x77f1) [0x7fdcd58637f1]
>>   5: (clone()+0x6d) [0x7fdcd4cb4ccd]
>>   NOTE: a copy of the executable, or `objdump -rdS<executable>` is needed to
>> interpret this.
>> 2012-05-24 13:24:06.327991 7fdcd1ee2700 -1 os/FileStore.cc: In function 'void
>> FileStore::sync_entry()' thread 7fdcd1ee2700 time 2012-05-24 13:24:06.326792
>> os/FileStore.cc: 3564: FAILED assert(0 == "async snap ioctl error")
>
> I just pushed a fix for this to master.

Great, that fixed it for me.

Thanks for the quick response!

>
> BTW, the real change happening with these patches is that --mkfs no longer
> clobbers existing data.  If you want to wipe out an osd and start anew,
> you need to rm -r (and btrfs sub delete snap_* and current), or re-run
> mkfs.btrfs.

Ah, OK.  It turns out I always run mkfs.btrfs anyway, but
this is good to know.

-- Jim

>
> Thanks for the report!
>
> sage
>
>
>
>>
>> FWIW, with commit 598dea12411 (filestore: mkfs: only
>> create snap_0 if we created current_op_seq) reverted,
>> I am able to create a new filesystem using the above
>> sequence, and a typical "mkcephfs --init-local-daemons osd"
>> looks like this:
>>
>> 2012-05-24 13:06:25.918663 7fe7ac829780 -1 filestore(/ram/mnt/ceph/data.osd.0)
>> could not find 23c2fcde/osd_superblock/0 in index: (2) No such file or
>> directory
>> 2012-05-24 13:06:26.301738 7fe7ac829780 -1 created object store
>> /ram/mnt/ceph/data.osd.0 journal /dev/mapper/cs32s01p2 for osd.0 fsid
>> f8cc9fa2-a300-45a1-ae6d-e0c0ef418d0f
>> creating private key for osd.0 keyring /mnt/ceph/misc.osd.0/keyring.osd.0
>> creating /mnt/ceph/misc.osd.0/keyring.osd.0
>>
>> Thanks -- Jim
>>
>> --
>> 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
>>
>>
>
>



^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2012-05-24 21:46 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-05-24 19:39 mkcephfs regression in current master branch Jim Schutt
2012-05-24 21:13 ` Sage Weil
2012-05-24 21:46   ` Jim Schutt

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.