And I forgot to mention that this 'bug' is still XFS dependent. I have the same setup RAID/LVM/virtio setup in use with ext4. Which works fine. Either ext4 does something wrong so that it works or not I can not tell. The end result is that ext4 works, xfs only with modification to the virtual machine setup. On 10/3/12 11:18 AM, Richard Neuboeck wrote: > Hi, > > just in case someone stumbles over this thread in search for help. I > found a solution. > > I upgraded the host machine from Ubuntu lucid to Ubuntu precise and > expected the same mounting behavior like in the virtual machine running > 'precise'. However on the host no error message showed up. > > Long story short after some test on the virtual machine configuration > (libvirt, qemu/kvm) it turned out to be the 'caching=none' option. After > changing this to <driver name='qemu' type='raw' cache='default'/> > everything works. > > Richard > > On 9/22/12 11:33 AM, Richard Neuboeck wrote: >> 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. >>> >>> >>> >>> _______________________________________________ >>> xfs mailing list >>> xfs@xxxxxxxxxxx >>> http://oss.sgi.com/mailman/listinfo/xfs >>> >>> >>> _______________________________________________ >>> xfs mailing list >>> xfs@xxxxxxxxxxx >>> http://oss.sgi.com/mailman/listinfo/xfs
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
