CEPH filesystem development
 help / color / mirror / Atom feed
* 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