* xfs mount fails 'can't read superblock'
@ 2012-09-18 8:49 Richard Neuboeck
2012-09-18 20:55 ` Dave Chinner
0 siblings, 1 reply; 6+ messages in thread
From: Richard Neuboeck @ 2012-09-18 8:49 UTC (permalink / raw)
To: xfs
[-- Attachment #1.1: Type: text/plain, Size: 3427 bytes --]
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@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.
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@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@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@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@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@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@tbi.univie.ac.at
[w] http://www.tbi.univie.ac.at/~hawk
---------------------------------------------------------------------
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 264 bytes --]
[-- Attachment #2: Type: text/plain, Size: 121 bytes --]
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: xfs mount fails 'can't read superblock' 2012-09-18 8:49 xfs mount fails 'can't read superblock' Richard Neuboeck @ 2012-09-18 20:55 ` Dave Chinner 2012-09-22 9:33 ` Richard Neuboeck 0 siblings, 1 reply; 6+ messages in thread From: Dave Chinner @ 2012-09-18 20:55 UTC (permalink / raw) To: Richard Neuboeck; +Cc: xfs On Tue, Sep 18, 2012 at 10:49:20AM +0200, Richard Neuboeck wrote: > 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. virtio configuration? (i.e. 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? > 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? > 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. Cheers, Dave. -- Dave Chinner david@fromorbit.com _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: xfs mount fails 'can't read superblock' 2012-09-18 20:55 ` Dave Chinner @ 2012-09-22 9:33 ` Richard Neuboeck 2012-10-03 9:18 ` Richard Neuboeck 0 siblings, 1 reply; 6+ messages in thread From: Richard Neuboeck @ 2012-09-22 9:33 UTC (permalink / raw) To: Dave Chinner; +Cc: xfs [-- Attachment #1.1: Type: text/plain, Size: 4451 bytes --] 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 #1.2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 264 bytes --] [-- Attachment #2: Type: text/plain, Size: 121 bytes --] _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: xfs mount fails 'can't read superblock' 2012-09-22 9:33 ` Richard Neuboeck @ 2012-10-03 9:18 ` Richard Neuboeck 2012-10-05 9:12 ` Richard Neuboeck 0 siblings, 1 reply; 6+ messages in thread From: Richard Neuboeck @ 2012-10-03 9:18 UTC (permalink / raw) To: xfs [-- Attachment #1.1: Type: text/plain, Size: 5326 bytes --] 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@oss.sgi.com >> http://oss.sgi.com/mailman/listinfo/xfs [-- Attachment #1.2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 264 bytes --] [-- Attachment #2: Type: text/plain, Size: 121 bytes --] _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: xfs mount fails 'can't read superblock' 2012-10-03 9:18 ` Richard Neuboeck @ 2012-10-05 9:12 ` Richard Neuboeck 2012-10-06 0:17 ` Dave Chinner 0 siblings, 1 reply; 6+ messages in thread From: Richard Neuboeck @ 2012-10-05 9:12 UTC (permalink / raw) To: xfs [-- Attachment #1.1: Type: text/plain, Size: 5981 bytes --] 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@oss.sgi.com >>> http://oss.sgi.com/mailman/listinfo/xfs >>> >>> >>> _______________________________________________ >>> xfs mailing list >>> xfs@oss.sgi.com >>> http://oss.sgi.com/mailman/listinfo/xfs [-- Attachment #1.2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 264 bytes --] [-- Attachment #2: Type: text/plain, Size: 121 bytes --] _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: xfs mount fails 'can't read superblock' 2012-10-05 9:12 ` Richard Neuboeck @ 2012-10-06 0:17 ` Dave Chinner 0 siblings, 0 replies; 6+ messages in thread From: Dave Chinner @ 2012-10-06 0:17 UTC (permalink / raw) To: Richard Neuboeck; +Cc: xfs On Fri, Oct 05, 2012 at 11:12:39AM +0200, Richard Neuboeck wrote: > 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. So, you converted it to use buffered IO. > And I forgot to mention that this 'bug' is still XFS dependent. It's not a bug if theproblem is a sector size mismatch in your configuration. You haven't provided any of the details that have been asked for to confirm this, so it would be appreciated if you could so we know in future.... > 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. ext4 only does filesystem block sized IOs, which by default will be 4k, and hence work just fine on a 4k sector size host filesystem. XFS does sector size IO in some cases, and that's where you appear to behaving problems. Assuming the problem is a sector size mismatch, then make your guest XFS filesystems use 4k sector size, and everything will be fine.... Cheers, Dave. -- Dave Chinner david@fromorbit.com _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2012-10-06 0:16 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-09-18 8:49 xfs mount fails 'can't read superblock' Richard Neuboeck 2012-09-18 20:55 ` Dave Chinner 2012-09-22 9:33 ` Richard Neuboeck 2012-10-03 9:18 ` Richard Neuboeck 2012-10-05 9:12 ` Richard Neuboeck 2012-10-06 0:17 ` Dave Chinner
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox