* 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox