xfs mount fails 'can't read superblock'

[Richard Neuboeck]

Hi XFS gurus,

I've a XFS related problem that boggles my find and I couldn't find a
solution yet.

I've got a virtual machine (huddle) that gets a ~66TB logical volume
from the host handed as (virtio) block device (/dev/vdb). For ease of
maintenance I didn't partition the device but formatted it directly with
xfs. The system at the time of formatting was Ubuntu Lucid 64bit.

A few days ago I upgraded the virtual machine to Ubuntu LTS 'precise',
Kernel 3.2, and got the following error while trying to mount the device:

root at huddle:~# mount /dev/vdb /mnt/storage
mount: /dev/vdb: can't read superblock

dmesg shows some more info:
root at huddle:~# dmesg | tail
[  672.774206] end_request: I/O error, dev vdb, sector 0
[  672.774393] XFS (vdb): SB buffer read failed

At first I thought the block device had some error and checked the
virtual machine configuration and host system.

From the host system (Ubuntu lucid 64bit, Kernel 2.6) I can still mount
the xfs formatted device without problems. I also ran xfs_repair -n that
didn't show any problem.

I tried to hand the virual machine a different ext4 formated block
device (also without partition and preformatted). This didn't yield any
mount problems.

The Ubuntu 'precise' machine has an older kernel (2.6.32-42) too.
Booting this kernel the xfs formatted block device gets mounted without
error.

The curious part is that it is still possible to mount the volume under
Kernel 3.2 without error using the loop option:

root at huddle:~# mount -v -t xfs -o loop /dev/vdb /mnt/storage/

Trying xfs_repair also brings up the I/O Error unless I use it with the
-f option under Kernel 3.2.

Obviously the problem is Kernel 3.2 related. I'm not sure if I'm at the
right place in the XFS Mailinglist but thought it would make a good
starting point since I couldn't find anything related in bugzilla or the
web in general and the problem didn't show up using ext4 (so may not be
a generic kernel problem).

Any suggestion for a solution (without partitioning the device) would be
greatly appreciated since the use of the loop back device doesn't
support quotas and I guess brings a performance penalty as well (but I
haven't tested it yet).

Here is some more information about the virtual machine:

It's using Ubuntu LTS 'precise' 64bit
root at huddle:~# uname -a
Linux huddle 3.2.0-30-generic #48-Ubuntu SMP Fri Aug 24 16:52:48 UTC
2012 x86_64 x86_64 x86_64 GNU/Linux

The XFS tools are the following version, though using kernel 2.6.32 the
same tools work without problem.
root at huddle:~# xfs_repair -V
xfs_repair version 3.1.7

That's how the logical volume from the host looks inside the virtual
machine:
root at huddle:~# ls -l /dev/vdb
brw-rw---- 1 root disk 253, 16 Sep 17 19:36 /dev/vdb

Running any kernel, blkid still identifies the device correctly as xfs
volume:
root at huddle:~# blkid /dev/vdb
/dev/vdb: UUID="5adcd575-d3f2-48c3-81de-104f125b275e" TYPE="xfs"

Thanks in advance.
Richard

-- 
---------------------------------------------------------------------
    Systemadministration
[a] Department for Theoretical Chemistry
    University of Vienna
    Waehringer Strasse 17/3/304, 1090 Wien, Austria
[p] +43 664 920 32 95
[m] hawk at tbi.univie.ac.at
[w] http://www.tbi.univie.ac.at/~hawk
---------------------------------------------------------------------











-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 264 bytes
Desc: OpenPGP digital signature
URL: <http://oss.sgi.com/pipermail/xfs/attachments/20120918/2d50f2cb/attachment.sig>