* btrfs_alloc_free_block
@ 2012-04-12 8:45 Wido den Hollander
0 siblings, 0 replies; only message in thread
From: Wido den Hollander @ 2012-04-12 8:45 UTC (permalink / raw)
To: ceph-devel@vger.kernel.org
Hi,
I just noticed some issues in my cluster where a couple of OSDs would
commit suicide due to I/O timeouts.
A quick check showed me: http://pastebin.com/uU1MJRPh
I killed (clean shutdown) osd.1 in this case and tried to start it
again, that seemed to go well, but then the btrfs mount failed:
http://pastebin.com/F1nSb67y
"btrfs: open_ctree failed"
root@atom0:/var/log/ceph# service ceph start osd.1
=== osd.1 ===
Mounting Btrfs on atom0:/var/lib/ceph/osd.1
Scanning for Btrfs filesystems
mount: wrong fs type, bad option, bad superblock on /dev/sdc,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so
failed: 'modprobe btrfs ; btrfs device scan || btrfsctl -a ; egrep -q
'^[^ ]+ /var/lib/ceph/osd.1' /proc/mounts || mount -t btrfs -o noatime
/dev/disk/by-id/scsi-SATA_WDC_WD20EARS-00_WD-WCAZA3231872
/var/lib/ceph/osd.1'
root@atom0:/var/log/ceph#
Has anyone seen this behavior with the 3.3.0 kernel?
My main concern is the fact that my filesystem won't mount anymore and I
have to re-format the whole OSD. This open_ctree problem keeps coming back.
Wido
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2012-04-12 8:45 UTC | newest]
Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-04-12 8:45 btrfs_alloc_free_block Wido den Hollander
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.