Hi Dave,
thanks for your help! You are absolutely right.
On 9/18/12 10:55 PM, Dave Chinner wrote:
> On Tue, Sep 18, 2012 at 10:49:20AM +0200, Richard Neuboeck wrote:
>> 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.
>
> virtio configuration? (i.e. cache=none?)
Yes. Virtio and cache=none.
>> 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:
>
> Upgraded from what?
Ubtunu Lucid.
>> root@huddle:~# mount /dev/vdb /mnt/storage
>> mount: /dev/vdb: can't read superblock
>>
>> dmesg shows some more info:
>> root@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.
>
> So the filesystem is accesible via direct IO from the host. What's
> the xfs_info output once it is mounted?
xfs_info on the host system shows a 4K sector size:
root@wirt2:~# xfs_info /mnt/temp/
meta-data=/dev/mapper/storage-huddle isize=256 agcount=66,
agsize=268435455 blks
= sectsz=4096 attr=2
data = bsize=4096 blocks=17572571136, imaxpct=5
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0
log =internal bsize=4096 blocks=521728, version=2
= sectsz=4096 sunit=1 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0
>> 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 newer kernel has a different buffer cache implementation, so
> sector sized IO (such as superblocks) is cached and issued
> differently.
>
>> The curious part is that it is still possible to mount the volume under
>> Kernel 3.2 without error using the loop option:
>>
>> root@huddle:~# mount -v -t xfs -o loop /dev/vdb /mnt/storage/
>
> Turns all IO into pagecache based IO, so 4k aligned. Will avoid any
> sector size mismatch issues.
>
>> Trying xfs_repair also brings up the I/O Error unless I use it with the
>> -f option under Kernel 3.2.
>
> -f can turn direct IO into buffered IO is there is a sector size
> mismatch between the filesystem and the underlying storage.
>
>> 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).
>
> Sounds like a sector size based problem to me - direct Io does
> sector aligned and sized IO, buffered IO does page sized IO. So my
> initial thought is that you've got a 512 byte sector filesystem on a
> 4k sector device....
>
>> Running any kernel, blkid still identifies the device correctly as xfs
>> volume:
>> root@huddle:~# blkid /dev/vdb
>> /dev/vdb: UUID="5adcd575-d3f2-48c3-81de-104f125b275e" TYPE="xfs"
>
> Buffered IO, again.
I verified it with a 512B sector loop back device which works fine with
xfs (or whatever the file system choice is).
I can only nod my head in shame. Though I know this may be the wrong
mailinglist for my problem I have absolutely no idea how to proceed.
Googling didn't reveal the holy grail yet. Is there a way to realign the
filesystem (without loosing the data on it)?
Thanks!
Richard
> Cheers,
>
> Dave.
>
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
