On Wed, 19 Jan 2011, Jim Schutt wrote: > Hi Greg, > > On Wed, 2011-01-19 at 10:00 -0700, Gregory Farnum wrote: > > On Wed, Jan 19, 2011 at 8:46 AM, Jim Schutt <jaschut@xxxxxxxxxx> wrote: > > > Hi, > > > > > > I've been experimenting with using cephfs to set > > > the object/stripe size on a Ceph filesystem root, > > > and it seems to not persist across a filesystem > > > restart. Is that expected behavior? > > > ... > > > Am I missing something? > > Hmmm, not that I see. It should definitely be a persistent setting. > > > > <debug_mode> > > Have you tried this on non-root directories, and were results the same > > or different? > > </debug_mode> > > -Greg > > > > I tried to test this, but got this instead after > restarting my filesystem: > > 2011-01-19 10:16:31.073571 7f318f7fe940 osd41 48 pg[3.62f( empty n=0 ec=2 les=18 47/47/9) [41] r=0 mlcod 0'0 !hml degraded] clear_prior > 2011-01-19 10:16:31.073584 7f318f7fe940 osd41 48 pg[3.62f( empty n=0 ec=2 les=18 48/48/9) [41,53] r=0 mlcod 0'0 !hml degraded] noting past interval(47-47 [41]/[41]) > 2011-01-19 10:16:31.073598 7f318f7fe940 osd41 48 pg[3.62f( empty n=0 ec=2 les=18 48/48/9) [41,53] r=0 mlcod 0'0 !hml degraded] cancel_recovery > 2011-01-19 10:16:31.073610 7f318f7fe940 osd41 48 pg[3.62f( empty n=0 ec=2 les=18 48/48/9) [41,53] r=0 mlcod 0'0 !hml degraded] clear_recovery_state > 2011-01-19 10:16:31.073623 7f318f7fe940 osd41 48 pg[3.62f( empty n=0 ec=2 les=18 48/48/9) [41,53] r=0 mlcod 0'0 !hml inactive] clear_primary_state > 2011-01-19 10:16:31.073653 7f318f7fe940 osd41 48 pg[3.62f( empty n=0 ec=2 les=18 48/48/9) [41,53] r=0 mlcod 0'0 !hml inactive] clear_prior > 2011-01-19 10:16:31.073668 7f318f7fe940 osd41 48 pg[3.62f( empty n=0 ec=2 les=18 48/48/9) [41,53] r=0 mlcod 0'0 !hml inactive] up [41] -> [41,53], acting [41] -> [41,53], role 0 -> 0 > 2011-01-19 10:16:31.073681 7f318f7fe940 osd41 48 pg[3.62f( empty n=0 ec=2 les=18 48/48/9) [41,53] r=0 mlcod 0'0 !hml inactive] on_change > 2011-01-19 10:16:31.073783 7f318f7fe940 osd41 48 pg[3.62f( empty n=0 ec=2 les=18 48/48/9) [41,53] r=0 mlcod 0'0 !hml inactive] [41] -> [41,53], replicas changed > 2011-01-19 10:16:31.092006 7f318f7fe940 osd41 48 write_superblock sb(01d356fc-7539-8c8d-7e49-8a2f42242802 osd41 e48 [1,48] lci=[9,23]) > os/FileStore.cc: In function 'void FileStore::sync_entry()': > os/FileStore.cc:2309: FAILED assert(r == 0) > ceph version 0.24.1 (commit:6152f5227d1ab177230211b6d25e62d6094e26e6) > 1: (FileStore::sync_entry()+0x25d9) [0x5a79a9] > 2: (FileStore::SyncThread::entry()+0xd) [0x522b7d] > 3: (Thread::_entry_func(void*)+0x7) [0x48a467] > 4: /lib64/libpthread.so.0 [0x7f319d05c73d] > 5: (clone()+0x6d) [0x7f319bf72f6d] > NOTE: a copy of the executable, or `objdump -rdS <executable>` is needed to interpret this. > > --- > > So the sequence of events was: > - create new file system, start, mount > - create a directory, change its object/stripe sizes (to 512 KiB) > - unmount, shut down filesystem, restart > ==> osd assert. > > What else do you need from me to debug this? This is unrelated... can you look at 'dmesg | tail' on that node and see if there are any btrfs messages? We've seen a problem where the btrfs snap create ioctl occasionally returns EINVAL and haven't been able to track it down yet. It's relatively rare, so restarting your osd will let you continue. (You may need to pass --osd-use-stale-snap 1 to make cosd start due to the timing of the crash.) For the set_layout, we should be able to reproduce that locally. Thanks! sage -- 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
