How to fix bad superblock or xfs_repair: error - read only 0 of 512 bytes

How to fix bad superblock or xfs_repair: error - read only 0 of 512 bytes

[Utpal Bora]

Hi,

My XFS home drive is corrupt after trying to extend it with lvm.
This is what I did to extend the partition.
1. Extend Volume group to use a new physical volume of around 1.2TB.
This was successful without any error.
    vgextend vg-1 /dev/sdc1

2. Extend logical volume (home-lv) to use the free space.
    lvextend -l 100%FREE /dev/mapper/vg--1-home--lv -r

3. Resized home-lv and reduce 55 GB
   lvreduce -L 55G  /dev/mapper/vg--1-home--lv -r

I assumed that -r will invoke xfs_grow internally.
Everything was working fine until the server was restarted.
After restart, the home volume is not mounting. Please see the following.

server% sudo mount -t xfs /dev/mapper/vg--1-home--lv /home
mount: /home: can't read superblock on /dev/mapper/vg--1-home--lv.

server% dmesg| tail
[162580.208796] attempt to access beyond end of device
[162580.208800] dm-3: rw=4096, want=6650552320, limit=6640066560
[162580.208805] XFS (dm-3): last sector read failed

server% sudo xfs_repair -n /dev/mapper/vg--1-home--lv
Phase 1 - find and verify superblock...
xfs_repair: error - read only 0 of 512 bytes

OS: Ubuntu Server 18.04.3
Kernel: 4.15.0-72-generic

I have gone through the earlier posts on this subject. They did not help me.

Is it possible to repair the XFS volume? Kindly suggest.

Regards,

Utpal Bora
Ph.D. Scholar
Computer Science & Engineering
IIT Hyderabad

Re: How to fix bad superblock or xfs_repair: error - read only 0 of 512 bytes

[Chris Murphy]

On Sat, Dec 28, 2019 at 4:12 AM Utpal Bora <cs14mtech11017@iith.ac.in> wrote:
>
> Hi,
>
> My XFS home drive is corrupt after trying to extend it with lvm.
> This is what I did to extend the partition.
> 1. Extend Volume group to use a new physical volume of around 1.2TB.
> This was successful without any error.
>     vgextend vg-1 /dev/sdc1
>
> 2. Extend logical volume (home-lv) to use the free space.
>     lvextend -l 100%FREE /dev/mapper/vg--1-home--lv -r

What approximate byte value is 100%FREE ?

> 3. Resized home-lv and reduce 55 GB
>    lvreduce -L 55G  /dev/mapper/vg--1-home--lv -r

If this is really a volume reduction, along with -r I would expect
this entire command to fail. XFS doesn't support shrink. Since a
successful LV shrink requires shrinking the file system first, or else
it results in truncation of the file system it contains and thus
damages it, off hand I think this is a bug in lvreduce, or possibly in
fsadm which is what -r calls to do the resize.

My suggestion is to make no further changes at all, no further
recovery attempts. And head over to the LVM list and make the same
post as above. It's very possible there's backup LVM metadata that
will reference the PE/LE's used in the LV prior to the lvreduce. By
restoring the LV using that exact same mapping, it should be possible
to recover the file system it contains. But only if you don't make
other attempts. The more additional attempts the greater the chance of
irreparable changes.

https://www.redhat.com/mailman/listinfo/linux-lvm

> I assumed that -r will invoke xfs_grow internally.

Right, but xfs_grow only grows. It doesn't shrink. So my expectation
is that the lvreduce command should fail without having made any
changes. And yet...

--
Chris Murphy

Re: How to fix bad superblock or xfs_repair: error - read only 0 of 512 bytes

[Eric Sandeen]

On Dec 28, 2019, at 3:11 AM, Utpal Bora <cs14mtech11017@iith.ac.in> wrote:
> 
> Hi,
> 
> My XFS home drive is corrupt after trying to extend it with lvm.
> This is what I did to extend the partition.
> 1. Extend Volume group to use a new physical volume of around 1.2TB.
> This was successful without any error.
>    vgextend vg-1 /dev/sdc1
> 
> 2. Extend logical volume (home-lv) to use the free space.
>    lvextend -l 100%FREE /dev/mapper/vg--1-home--lv -r
> 
This probably invoked xfs_growfs

> 3. Resized home-lv and reduce 55 GB
>   lvreduce -L 55G  /dev/mapper/vg--1-home--lv -r
> 
XFS cannot shrink.  This corrupted your filesystem by truncating the block device.

> I assumed that -r will invoke xfs_grow internally.
> Everything was working fine until the server was restarted.
> After restart, the home volume is not mounting. Please see the following.
> 
> server% sudo mount -t xfs /dev/mapper/vg--1-home--lv /home
> mount: /home: can't read superblock on /dev/mapper/vg--1-home--lv.
> 
> server% dmesg| tail
> [162580.208796] attempt to access beyond end of device
> [162580.208800] dm-3: rw=4096, want=6650552320, limit=6640066560
> [162580.208805] XFS (dm-3): last sector read failed

Because you chopped off 55g from the end.

> server% sudo xfs_repair -n

Repair cannot read blocks that have been removed from the filesystem.


> /dev/mapper/vg--1-home--lv
> Phase 1 - find and verify superblock...
> xfs_repair: error - read only 0 of 512 bytes

Failed to read a backup super beyond the end of the reduced lv.

Grow the lv back to 100% I.e. the size before the lvreduce and it’ll probably be ok again

-Eric

> OS: Ubuntu Server 18.04.3
> Kernel: 4.15.0-72-generic
> 
> I have gone through the earlier posts on this subject. They did not help me.
> 
> Is it possible to repair the XFS volume? Kindly suggest.
> 
> Regards,
> 
> Utpal Bora
> Ph.D. Scholar
> Computer Science & Engineering
> IIT Hyderabad
> 

Re: How to fix bad superblock or xfs_repair: error - read only 0 of 512 bytes

[Utpal Bora]

Hi Eric,

Thank you for your help. Growing back lv to original size helped.

I am really thankful.

Is there a way for lvm to warn users while invoking lvreduce to check
if the file system should be shrunk before lvreduce.

Regards,

Utpal Bora
Ph.D. Scholar
Computer Science & Engineering
IIT Hyderabad
http://utpalbora.com
PGP key fingerprint: 2F12 635E 409F 11AC 1502  BB41 7705 9980 A062 FA70

Regards,

Utpal Bora
Ph.D. Scholar
Computer Science & Engineering
IIT Hyderabad
http://utpalbora.com
PGP key fingerprint: 2F12 635E 409F 11AC 1502  BB41 7705 9980 A062 FA70



On Sun, Dec 29, 2019 at 10:13 AM Eric Sandeen <sandeen@sandeen.net> wrote:
>
> On Dec 28, 2019, at 3:11 AM, Utpal Bora <cs14mtech11017@iith.ac.in> wrote:
> >
> > Hi,
> >
> > My XFS home drive is corrupt after trying to extend it with lvm.
> > This is what I did to extend the partition.
> > 1. Extend Volume group to use a new physical volume of around 1.2TB.
> > This was successful without any error.
> >    vgextend vg-1 /dev/sdc1
> >
> > 2. Extend logical volume (home-lv) to use the free space.
> >    lvextend -l 100%FREE /dev/mapper/vg--1-home--lv -r
> >
> This probably invoked xfs_growfs
>
> > 3. Resized home-lv and reduce 55 GB
> >   lvreduce -L 55G  /dev/mapper/vg--1-home--lv -r
> >
> XFS cannot shrink.  This corrupted your filesystem by truncating the block device.
>
> > I assumed that -r will invoke xfs_grow internally.
> > Everything was working fine until the server was restarted.
> > After restart, the home volume is not mounting. Please see the following.
> >
> > server% sudo mount -t xfs /dev/mapper/vg--1-home--lv /home
> > mount: /home: can't read superblock on /dev/mapper/vg--1-home--lv.
> >
> > server% dmesg| tail
> > [162580.208796] attempt to access beyond end of device
> > [162580.208800] dm-3: rw=4096, want=6650552320, limit=6640066560
> > [162580.208805] XFS (dm-3): last sector read failed
>
> Because you chopped off 55g from the end.
>
> > server% sudo xfs_repair -n
>
> Repair cannot read blocks that have been removed from the filesystem.
>
>
> > /dev/mapper/vg--1-home--lv
> > Phase 1 - find and verify superblock...
> > xfs_repair: error - read only 0 of 512 bytes
>
> Failed to read a backup super beyond the end of the reduced lv.
>
> Grow the lv back to 100% I.e. the size before the lvreduce and it’ll probably be ok again
>
> -Eric
>
> > OS: Ubuntu Server 18.04.3
> > Kernel: 4.15.0-72-generic
> >
> > I have gone through the earlier posts on this subject. They did not help me.
> >
> > Is it possible to repair the XFS volume? Kindly suggest.
> >
> > Regards,
> >
> > Utpal Bora
> > Ph.D. Scholar
> > Computer Science & Engineering
> > IIT Hyderabad
> >
>

Re: How to fix bad superblock or xfs_repair: error - read only 0 of 512 bytes

[Utpal Bora]

Hello Chris,

Thank you for your response. I could solve the problem by extending
the lv as Eric suggested.

Regards,

Utpal Bora
Ph.D. Scholar
Computer Science & Engineering
IIT Hyderabad
http://utpalbora.com
PGP key fingerprint: 2F12 635E 409F 11AC 1502  BB41 7705 9980 A062 FA70


On Sun, Dec 29, 2019 at 8:45 AM Chris Murphy <lists@colorremedies.com> wrote:
>
> On Sat, Dec 28, 2019 at 4:12 AM Utpal Bora <cs14mtech11017@iith.ac.in> wrote:
> >
> > Hi,
> >
> > My XFS home drive is corrupt after trying to extend it with lvm.
> > This is what I did to extend the partition.
> > 1. Extend Volume group to use a new physical volume of around 1.2TB.
> > This was successful without any error.
> >     vgextend vg-1 /dev/sdc1
> >
> > 2. Extend logical volume (home-lv) to use the free space.
> >     lvextend -l 100%FREE /dev/mapper/vg--1-home--lv -r
>
> What approximate byte value is 100%FREE ?
>
> > 3. Resized home-lv and reduce 55 GB
> >    lvreduce -L 55G  /dev/mapper/vg--1-home--lv -r
>
> If this is really a volume reduction, along with -r I would expect
> this entire command to fail. XFS doesn't support shrink. Since a
> successful LV shrink requires shrinking the file system first, or else
> it results in truncation of the file system it contains and thus
> damages it, off hand I think this is a bug in lvreduce, or possibly in
> fsadm which is what -r calls to do the resize.
>
> My suggestion is to make no further changes at all, no further
> recovery attempts. And head over to the LVM list and make the same
> post as above. It's very possible there's backup LVM metadata that
> will reference the PE/LE's used in the LV prior to the lvreduce. By
> restoring the LV using that exact same mapping, it should be possible
> to recover the file system it contains. But only if you don't make
> other attempts. The more additional attempts the greater the chance of
> irreparable changes.
>
> https://www.redhat.com/mailman/listinfo/linux-lvm
>
> > I assumed that -r will invoke xfs_grow internally.
>
> Right, but xfs_grow only grows. It doesn't shrink. So my expectation
> is that the lvreduce command should fail without having made any
> changes. And yet...
>
> --
> Chris Murphy

Re: How to fix bad superblock or xfs_repair: error - read only 0 of 512 bytes

[Christian Kildau]

On Jan 24, 2012, at 6:25 PM, Roger Willcocks wrote:

> 
> On Tue, 2012-01-24 at 09:57 -0600, Eric Sandeen wrote:
>> On 1/24/12 9:52 AM, Christian Kildau wrote:
>>> On Jan 24, 2012, at 4:50 PM, Eric Sandeen wrote:
>>> 
> ...
>>>> Can you run the hdparm command Roger suggested on your original hard drive, please?
>>> 
>>> Sure, here it is:
>>> 
>>> /dev/sde:
>>> max sectors   = 2930275055/2930277168, HPA is enabled
>>                                          ^^^^^^^^^^^^^^
>> 
>> ding ding ding, we have a winner.
>> 
>> 2930277168-2930275055 = 2113 which is about how much xfs tried to read past the end.
>> 
>> Something about the ubuntu upgrade messed with your disk.
>> 
>> I'd press them very hard to investigate & resolve that.  You can probably use hdparm
>> to remove the HPA and get your space back but this is beyond my expertise &
>> familiarity.  It'd be interesting to know what is _in_ the HPA area first.
>> 
> 
> Kernel commit d8d9129ea28e2177749627c82962feb26e8d11e9 added code to
> notice if a disk partition extends into the hidden area and 'unlocks'
> the hidden area (uses the full disk capacity) if necessary.
> 
> But if there's no partition table (the entire disk is formatted as a
> single filesystem) the heuristic can't work.
> 
> http://www.spinics.net/lists/linux-ide/msg40244.html suggests that
> Ubuntu no longer always unlocks, but uses the heuristic above. In the
> same message Alan Cox says Ubuntu 'made a bad mistake on that one.'
> 
> -- 
> Roger Willcocks <roger@filmlight.ltd.uk>
> 



Good to know! Made me choose another OS for the next servers!

Thanks
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: How to fix bad superblock or xfs_repair: error - read only 0 of 512 bytes

[Roger Willcocks]

On Tue, 2012-01-24 at 09:57 -0600, Eric Sandeen wrote:
> On 1/24/12 9:52 AM, Christian Kildau wrote:
> > On Jan 24, 2012, at 4:50 PM, Eric Sandeen wrote:
> > 
...
> >> Can you run the hdparm command Roger suggested on your original hard drive, please?
> > 
> > Sure, here it is:
> > 
> > /dev/sde:
> >  max sectors   = 2930275055/2930277168, HPA is enabled
>                                           ^^^^^^^^^^^^^^
> 
> ding ding ding, we have a winner.
> 
> 2930277168-2930275055 = 2113 which is about how much xfs tried to read past the end.
> 
> Something about the ubuntu upgrade messed with your disk.
> 
> I'd press them very hard to investigate & resolve that.  You can probably use hdparm
> to remove the HPA and get your space back but this is beyond my expertise &
> familiarity.  It'd be interesting to know what is _in_ the HPA area first.
> 

Kernel commit d8d9129ea28e2177749627c82962feb26e8d11e9 added code to
notice if a disk partition extends into the hidden area and 'unlocks'
the hidden area (uses the full disk capacity) if necessary.

But if there's no partition table (the entire disk is formatted as a
single filesystem) the heuristic can't work.

http://www.spinics.net/lists/linux-ide/msg40244.html suggests that
Ubuntu no longer always unlocks, but uses the heuristic above. In the
same message Alan Cox says Ubuntu 'made a bad mistake on that one.'

-- 
Roger Willcocks <roger@filmlight.ltd.uk>

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: How to fix bad superblock or xfs_repair: error - read only 0 of 512 bytes

[Eric Sandeen]

On 1/24/12 9:52 AM, Christian Kildau wrote:
> On Jan 24, 2012, at 4:50 PM, Eric Sandeen wrote:
> 
>> On 1/24/12 9:46 AM, Christian Kildau wrote:
>>>
>>> On Jan 24, 2012, at 3:12 PM, Roger Willcocks wrote:
>>>
>>>>
>>>> On Tue, 2012-01-24 at 11:13 +0100, Christian Kildau wrote:
>>>>> Top posting... sorry.
>>>>>
>>>>> I have now found dozens of other users with a similar issue! e.g.
>>>>> http://www.linuxquestions.org/questions/linux-general-1/cannot-mount-hard-disk-block-count-exceeds-size-of-device-bad-partition-table-880149/
>>>>>
>>>>> To make it short all of these users were running ext4 and a fs resize to the new geometry fixed their problems! Sadly XFS doesn't support shrinking the fs(?).
>>>>>
>>>>
>>>> It seems fairly clear that your drive or the bios is lying about its
>>>> capacity. The filesystem occupies the entire disk, but the disk has
>>>> become 'smaller'. A quick web search suggests a 'hidden protected area'
>>>> - the two block counts in this link line up with the before and after
>>>> sizes you're seeing:
>>>>
>>>> http://lime-technology.com/forum/index.php?topic=13440.0;wap2
>>>>
>>>> It would be instructive to see what 'hdparm -N /dev/sdd' says on your
>>>> system. And a dmesg log would be handy too.
>>>>
>>>> Note that this is /not/ a problem with xfs. The right fix is to tell the
>>>> drive to report its actual capacity, not to shrink the filesystem.
>>>
>>> I do understand that is definitely not an XFS issue, but some strange issue with ubuntu or their kernel patches...
>>>
>>> I got my data back by dumping the entire hdd (it was partitionless nevertheless) to a bigger 2TB hdd.
>>> XFS mounts without any problems and I can restore my data.
>>>
>>> Thanks all for your help!
>>
>> It's likely still missing the end of the filesystem, though.
>>
>> Can you run the hdparm command Roger suggested on your original hard drive, please?
> 
> Sure, here it is:
> 
> /dev/sde:
>  max sectors   = 2930275055/2930277168, HPA is enabled
                                          ^^^^^^^^^^^^^^

ding ding ding, we have a winner.

2930277168-2930275055 = 2113 which is about how much xfs tried to read past the end.

Something about the ubuntu upgrade messed with your disk.

I'd press them very hard to investigate & resolve that.  You can probably use hdparm
to remove the HPA and get your space back but this is beyond my expertise &
familiarity.  It'd be interesting to know what is _in_ the HPA area first.

-Eric

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: How to fix bad superblock or xfs_repair: error - read only 0 of 512 bytes

[Christian Kildau]

On Jan 24, 2012, at 4:50 PM, Eric Sandeen wrote:

> On 1/24/12 9:46 AM, Christian Kildau wrote:
>> 
>> On Jan 24, 2012, at 3:12 PM, Roger Willcocks wrote:
>> 
>>> 
>>> On Tue, 2012-01-24 at 11:13 +0100, Christian Kildau wrote:
>>>> Top posting... sorry.
>>>> 
>>>> I have now found dozens of other users with a similar issue! e.g.
>>>> http://www.linuxquestions.org/questions/linux-general-1/cannot-mount-hard-disk-block-count-exceeds-size-of-device-bad-partition-table-880149/
>>>> 
>>>> To make it short all of these users were running ext4 and a fs resize to the new geometry fixed their problems! Sadly XFS doesn't support shrinking the fs(?).
>>>> 
>>> 
>>> It seems fairly clear that your drive or the bios is lying about its
>>> capacity. The filesystem occupies the entire disk, but the disk has
>>> become 'smaller'. A quick web search suggests a 'hidden protected area'
>>> - the two block counts in this link line up with the before and after
>>> sizes you're seeing:
>>> 
>>> http://lime-technology.com/forum/index.php?topic=13440.0;wap2
>>> 
>>> It would be instructive to see what 'hdparm -N /dev/sdd' says on your
>>> system. And a dmesg log would be handy too.
>>> 
>>> Note that this is /not/ a problem with xfs. The right fix is to tell the
>>> drive to report its actual capacity, not to shrink the filesystem.
>> 
>> I do understand that is definitely not an XFS issue, but some strange issue with ubuntu or their kernel patches...
>> 
>> I got my data back by dumping the entire hdd (it was partitionless nevertheless) to a bigger 2TB hdd.
>> XFS mounts without any problems and I can restore my data.
>> 
>> Thanks all for your help!
> 
> It's likely still missing the end of the filesystem, though.
> 
> Can you run the hdparm command Roger suggested on your original hard drive, please?

Sure, here it is:

/dev/sde:
 max sectors   = 2930275055/2930277168, HPA is enabled
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: How to fix bad superblock or xfs_repair: error - read only 0 of 512 bytes

[Eric Sandeen]

On 1/24/12 9:46 AM, Christian Kildau wrote:
> 
> On Jan 24, 2012, at 3:12 PM, Roger Willcocks wrote:
> 
>>
>> On Tue, 2012-01-24 at 11:13 +0100, Christian Kildau wrote:
>>> Top posting... sorry.
>>>
>>> I have now found dozens of other users with a similar issue! e.g.
>>> http://www.linuxquestions.org/questions/linux-general-1/cannot-mount-hard-disk-block-count-exceeds-size-of-device-bad-partition-table-880149/
>>>
>>> To make it short all of these users were running ext4 and a fs resize to the new geometry fixed their problems! Sadly XFS doesn't support shrinking the fs(?).
>>>
>>
>> It seems fairly clear that your drive or the bios is lying about its
>> capacity. The filesystem occupies the entire disk, but the disk has
>> become 'smaller'. A quick web search suggests a 'hidden protected area'
>> - the two block counts in this link line up with the before and after
>> sizes you're seeing:
>>
>> http://lime-technology.com/forum/index.php?topic=13440.0;wap2
>>
>> It would be instructive to see what 'hdparm -N /dev/sdd' says on your
>> system. And a dmesg log would be handy too.
>>
>> Note that this is /not/ a problem with xfs. The right fix is to tell the
>> drive to report its actual capacity, not to shrink the filesystem.
> 
> I do understand that is definitely not an XFS issue, but some strange issue with ubuntu or their kernel patches...
> 
> I got my data back by dumping the entire hdd (it was partitionless nevertheless) to a bigger 2TB hdd.
> XFS mounts without any problems and I can restore my data.
> 
> Thanks all for your help!

It's likely still missing the end of the filesystem, though.

Can you run the hdparm command Roger suggested on your original hard drive, please?

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: How to fix bad superblock or xfs_repair: error - read only 0 of 512 bytes

[Christian Kildau]

On Jan 24, 2012, at 3:12 PM, Roger Willcocks wrote:

> 
> On Tue, 2012-01-24 at 11:13 +0100, Christian Kildau wrote:
>> Top posting... sorry.
>> 
>> I have now found dozens of other users with a similar issue! e.g.
>> http://www.linuxquestions.org/questions/linux-general-1/cannot-mount-hard-disk-block-count-exceeds-size-of-device-bad-partition-table-880149/
>> 
>> To make it short all of these users were running ext4 and a fs resize to the new geometry fixed their problems! Sadly XFS doesn't support shrinking the fs(?).
>> 
> 
> It seems fairly clear that your drive or the bios is lying about its
> capacity. The filesystem occupies the entire disk, but the disk has
> become 'smaller'. A quick web search suggests a 'hidden protected area'
> - the two block counts in this link line up with the before and after
> sizes you're seeing:
> 
> http://lime-technology.com/forum/index.php?topic=13440.0;wap2
> 
> It would be instructive to see what 'hdparm -N /dev/sdd' says on your
> system. And a dmesg log would be handy too.
> 
> Note that this is /not/ a problem with xfs. The right fix is to tell the
> drive to report its actual capacity, not to shrink the filesystem.

I do understand that is definitely not an XFS issue, but some strange issue with ubuntu or their kernel patches...

I got my data back by dumping the entire hdd (it was partitionless nevertheless) to a bigger 2TB hdd.
XFS mounts without any problems and I can restore my data.

Thanks all for your help!
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: How to fix bad superblock or xfs_repair: error - read only 0 of 512 bytes

[Roger Willcocks]

On Tue, 2012-01-24 at 11:13 +0100, Christian Kildau wrote:
> Top posting... sorry.
> 
> I have now found dozens of other users with a similar issue! e.g.
> http://www.linuxquestions.org/questions/linux-general-1/cannot-mount-hard-disk-block-count-exceeds-size-of-device-bad-partition-table-880149/
> 
> To make it short all of these users were running ext4 and a fs resize to the new geometry fixed their problems! Sadly XFS doesn't support shrinking the fs(?).
> 

It seems fairly clear that your drive or the bios is lying about its
capacity. The filesystem occupies the entire disk, but the disk has
become 'smaller'. A quick web search suggests a 'hidden protected area'
- the two block counts in this link line up with the before and after
sizes you're seeing:

http://lime-technology.com/forum/index.php?topic=13440.0;wap2

It would be instructive to see what 'hdparm -N /dev/sdd' says on your
system. And a dmesg log would be handy too.

Note that this is /not/ a problem with xfs. The right fix is to tell the
drive to report its actual capacity, not to shrink the filesystem.


_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: How to fix bad superblock or xfs_repair: error - read only 0 of 512 bytes

[Christian Kildau]

Top posting... sorry.

I have now found dozens of other users with a similar issue! e.g.
http://www.linuxquestions.org/questions/linux-general-1/cannot-mount-hard-disk-block-count-exceeds-size-of-device-bad-partition-table-880149/

To make it short all of these users were running ext4 and a fs resize to the new geometry fixed their problems! Sadly XFS doesn't support shrinking the fs(?).



On Jan 24, 2012, at 6:04 AM, Eric Sandeen wrote:

> On 1/23/12 3:23 AM, Christian Kildau wrote:
>> On Jan 23, 2012, at 5:31 AM, Dave Chinner wrote:
>> 
>>> On Sat, Jan 21, 2012 at 11:29:15AM +0100, Christian Kildau wrote:
>>>> Sorry if this message appears twice!
>>>> 
> 
> Argh.  ;)
> 
>>>> 
>>>> Hello,
>>>> 
>>>> I'm having some very serious issues with XFS after upgrading from a
>>>> Linux Distro running Ubuntu 2.6.32 to 3.2.
>>>> 
>>>> It seems like my filesystems are damaged after attaching them to a
>>>> Linux 3.2 server. I am also no longer able to mount the hdd on the old
>>>> server that is still running 2.6.32!
>>> 
>>> I take it that you are using external storage of some kind? Can you
>>> describe it?
>> 
>> This hdd is connected via e-sata, but it doesn't make any difference if I directly connect it internally via sata.
>> Also it doesn't make any difference if I connect it back to the 'old' server
>> 
>>> 
>>>> (I created the xfs filesystem on the entire hdd, not on a partition,
>>>> so /dev/sdd is not a typo)
> 
> I wonder if your installer helpfully scribbled something on it since it
> had no partitions (which should be safe, but there are dumb apps out there).
> 
>>>> $ sudo mount -t xfs /dev/sdd /media/
>>>> mount: /dev/sdd: can't read superblock
>>>> (dmesg)
>>>> [236659.912663] attempt to access beyond end of device
>>>> [236659.912667] sdd: rw=32, want=2930277168, limit=2930275055
>>>> [236659.912670] XFS (sdd): last sector read failed
>>> 
>>> So XFS has asked to read 2113 sectors beyond the size of the device
>>> that the kernel is reporting. What is the output of
>>> /proc/partitions?
>> 
>> $ grep sdd /proc/partitions 
>>   8       64 1465137527 sdd
> 
> so 1465137527*1024 = 1500300827648 bytes
> 
> From the strace repair is trying to read at:
> 
> pread(4, "", 512, 1500301909504)        = 0
> 
> which is about 1 meg past the end of the device.
> 
>>> 
>>>> $ sudo xfs_check /dev/sdd
>>>> xfs_check: error - read only 0 of 512 bytes
>>>> 
>>>> $ sudo xfs_repair /dev/sdd
>>>> Phase 1 - find and verify superblock...
>>>> xfs_repair: error - read only 0 of 512 bytes
>>> 
>>> So both buffered and direct IO to the first block in the block
>>> device are failing. I'd say your problems have nothing to do with
>>> XFS. However, can you strace them and find out what the error that
>>> is occuring actually is?
>> 
>> Strace is giving me:
>> wait4(-1, xfs_check: /dev/sdd is not a valid XFS filesystem (unexpected SB magic number 0x00000000)
> 
> now that is something else...
> 
>> xfs_check: WARNING - filesystem uses v1 dirs,limited functionality provided.
>> xfs_check: read failed: Invalid argument
>> cache_node_purge: refcount was 1, not zero (node=0x21ecef0)
>> xfs_check: cannot read root inode (22)
>> bad superblock magic number 0, giving up
> 
> those are different failures than first reported....
> 
> xfs_db -c "sb 0" -c "p" /dev/sdd still might be interesting.
> 
> -Eric
> 
>> I attached the entire strace logs to this email.
>> 
>> 
>> 
>> 
>> 
>> Do you have any idea what has caused this or how to fix it?
>> 
>> Thanks in advance!
>> Chris
>> 
>> 
>> 
>> _______________________________________________
>> 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

Re: How to fix bad superblock or xfs_repair: error - read only 0 of 512 bytes

[Christian Kildau]

On Jan 24, 2012, at 6:04 AM, Eric Sandeen wrote:

> On 1/23/12 3:23 AM, Christian Kildau wrote:
>> On Jan 23, 2012, at 5:31 AM, Dave Chinner wrote:
>> 
>>> On Sat, Jan 21, 2012 at 11:29:15AM +0100, Christian Kildau wrote:
>>>> Sorry if this message appears twice!
>>>> 
> 
> Argh.  ;)
> 
>>>> 
>>>> Hello,
>>>> 
>>>> I'm having some very serious issues with XFS after upgrading from a
>>>> Linux Distro running Ubuntu 2.6.32 to 3.2.
>>>> 
>>>> It seems like my filesystems are damaged after attaching them to a
>>>> Linux 3.2 server. I am also no longer able to mount the hdd on the old
>>>> server that is still running 2.6.32!
>>> 
>>> I take it that you are using external storage of some kind? Can you
>>> describe it?
>> 
>> This hdd is connected via e-sata, but it doesn't make any difference if I directly connect it internally via sata.
>> Also it doesn't make any difference if I connect it back to the 'old' server
>> 
>>> 
>>>> (I created the xfs filesystem on the entire hdd, not on a partition,
>>>> so /dev/sdd is not a typo)
> 
> I wonder if your installer helpfully scribbled something on it since it
> had no partitions (which should be safe, but there are dumb apps out there).

This is a new system. I connected the hdd waaay after the installation. So the installer has never seen it. ;)

> 
>>>> $ sudo mount -t xfs /dev/sdd /media/
>>>> mount: /dev/sdd: can't read superblock
>>>> (dmesg)
>>>> [236659.912663] attempt to access beyond end of device
>>>> [236659.912667] sdd: rw=32, want=2930277168, limit=2930275055
>>>> [236659.912670] XFS (sdd): last sector read failed
>>> 
>>> So XFS has asked to read 2113 sectors beyond the size of the device
>>> that the kernel is reporting. What is the output of
>>> /proc/partitions?
>> 
>> $ grep sdd /proc/partitions 
>>   8       64 1465137527 sdd
> 
> so 1465137527*1024 = 1500300827648 bytes
> 
> From the strace repair is trying to read at:
> 
> pread(4, "", 512, 1500301909504)        = 0
> 
> which is about 1 meg past the end of the device.

That's weird! Any chance left I can fix this?


> 
>>> 
>>>> $ sudo xfs_check /dev/sdd
>>>> xfs_check: error - read only 0 of 512 bytes
>>>> 
>>>> $ sudo xfs_repair /dev/sdd
>>>> Phase 1 - find and verify superblock...
>>>> xfs_repair: error - read only 0 of 512 bytes
>>> 
>>> So both buffered and direct IO to the first block in the block
>>> device are failing. I'd say your problems have nothing to do with
>>> XFS. However, can you strace them and find out what the error that
>>> is occuring actually is?
>> 
>> Strace is giving me:
>> wait4(-1, xfs_check: /dev/sdd is not a valid XFS filesystem (unexpected SB magic number 0x00000000)
> 
> now that is something else…

Yes, sorry. that was my fault. Wrong hdd. see my other message for the correct straces.

> 
>> xfs_check: WARNING - filesystem uses v1 dirs,limited functionality provided.
>> xfs_check: read failed: Invalid argument
>> cache_node_purge: refcount was 1, not zero (node=0x21ecef0)
>> xfs_check: cannot read root inode (22)
>> bad superblock magic number 0, giving up
> 
> those are different failures than first reported....
> 
> xfs_db -c "sb 0" -c "p" /dev/sdd still might be interesting.
> 

xfs_db: error - read only 0 of 512 bytes
magicnum = 0x58465342
blocksize = 4096
dblocks = 366284646
rblocks = 0
rextents = 0
uuid = 65b7d940-6577-4384-b7ba-f051300f2d56
logstart = 268435460
rootino = 128
rbmino = 129
rsumino = 130
rextsize = 1
agblocks = 91571162
agcount = 4
rbmblocks = 0
logblocks = 32768
versionnum = 0xb4a4
sectsize = 512
inodesize = 256
inopblock = 16
fname = "\000\000\000\000\000\000\000\000\000\000\000\000"
blocklog = 12
sectlog = 9
inodelog = 8
inopblog = 4
agblklog = 27
rextslog = 0
inprogress = 0
imax_pct = 5
icount = 5184
ifree = 16
fdblocks = 54646459
frextents = 0
uquotino = 0
gquotino = 0
qflags = 0
flags = 0
shared_vn = 0
inoalignmt = 2
unit = 0
width = 0
dirblklog = 0
logsectlog = 0
logsectsize = 0
logsunit = 1
features2 = 0x8
bad_features2 = 0x8

I don't get anything useful from that information ;)


Thanks in advance!
Chris
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: How to fix bad superblock or xfs_repair: error - read only 0 of 512 bytes

[Eric Sandeen]

On 1/23/12 3:23 AM, Christian Kildau wrote:
> On Jan 23, 2012, at 5:31 AM, Dave Chinner wrote:
> 
>> On Sat, Jan 21, 2012 at 11:29:15AM +0100, Christian Kildau wrote:
>>> Sorry if this message appears twice!
>>>

Argh.  ;)

>>>
>>> Hello,
>>>
>>> I'm having some very serious issues with XFS after upgrading from a
>>> Linux Distro running Ubuntu 2.6.32 to 3.2.
>>>
>>> It seems like my filesystems are damaged after attaching them to a
>>> Linux 3.2 server. I am also no longer able to mount the hdd on the old
>>> server that is still running 2.6.32!
>>
>> I take it that you are using external storage of some kind? Can you
>> describe it?
> 
> This hdd is connected via e-sata, but it doesn't make any difference if I directly connect it internally via sata.
> Also it doesn't make any difference if I connect it back to the 'old' server
> 
>>
>>> (I created the xfs filesystem on the entire hdd, not on a partition,
>>> so /dev/sdd is not a typo)

I wonder if your installer helpfully scribbled something on it since it
had no partitions (which should be safe, but there are dumb apps out there).

>>> $ sudo mount -t xfs /dev/sdd /media/
>>> mount: /dev/sdd: can't read superblock
>>> (dmesg)
>>> [236659.912663] attempt to access beyond end of device
>>> [236659.912667] sdd: rw=32, want=2930277168, limit=2930275055
>>> [236659.912670] XFS (sdd): last sector read failed
>>
>> So XFS has asked to read 2113 sectors beyond the size of the device
>> that the kernel is reporting. What is the output of
>> /proc/partitions?
> 
> $ grep sdd /proc/partitions 
>    8       64 1465137527 sdd

so 1465137527*1024 = 1500300827648 bytes

>From the strace repair is trying to read at:

pread(4, "", 512, 1500301909504)        = 0

which is about 1 meg past the end of the device.

>>
>>> $ sudo xfs_check /dev/sdd
>>> xfs_check: error - read only 0 of 512 bytes
>>>
>>> $ sudo xfs_repair /dev/sdd
>>> Phase 1 - find and verify superblock...
>>> xfs_repair: error - read only 0 of 512 bytes
>>
>> So both buffered and direct IO to the first block in the block
>> device are failing. I'd say your problems have nothing to do with
>> XFS. However, can you strace them and find out what the error that
>> is occuring actually is?
> 
> Strace is giving me:
> wait4(-1, xfs_check: /dev/sdd is not a valid XFS filesystem (unexpected SB magic number 0x00000000)

now that is something else...

> xfs_check: WARNING - filesystem uses v1 dirs,limited functionality provided.
> xfs_check: read failed: Invalid argument
> cache_node_purge: refcount was 1, not zero (node=0x21ecef0)
> xfs_check: cannot read root inode (22)
> bad superblock magic number 0, giving up

those are different failures than first reported....

xfs_db -c "sb 0" -c "p" /dev/sdd still might be interesting.

-Eric

> I attached the entire strace logs to this email.
> 
> 
> 
> 
> 
> Do you have any idea what has caused this or how to fix it?
> 
> Thanks in advance!
> Chris
> 
> 
> 
> _______________________________________________
> 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

Re: How to fix bad superblock or xfs_repair: error - read only 0 of 512 bytes

[Eric Sandeen]

On 1/21/12 4:03 AM, Christian Kildau wrote:
> Hello,
> 
> I'm having some very serious issues with XFS after upgrading from a
> Linux Distro running Ubuntu 2.6.32 to 3.2.
> 
> It seems like my filesystems are damaged after attaching them to a
> Linux 3.2 server. I am also no longer able to mount the hdd on the
> old server that is still running 2.6.32!

did you do anything else at all besides simply boot a 3.2 kernel?

Or was this a whole distro upgrade?  And who knows what the installer
did...?

> 'test disk' does find the filesystem as XFS 4 and i created a 1.5TB
> dump of it to another hdd.
> 
> (I created the xfs filesystem on the entire hdd, not on a partition,
> so /dev/sdd is not a typo)

is sdd a single disk or something like lvm/md?

what does grep sdd /proc/partitions say?

And

# xfs_db -c "sb 0" -c "p" /dev/sdd

> 
> $ sudo mount -t xfs /dev/sdd /media/
> mount: /dev/sdd: can't read superblock
> (dmesg)
> [236659.912663] attempt to access beyond end of device
> [236659.912667] sdd: rw=32, want=2930277168, limit=2930275055
> [236659.912670] XFS (sdd): last sector read failed
> 
> $ sudo xfs_check /dev/sdd
> xfs_check: error - read only 0 of 512 bytes
> 
> $ sudo xfs_repair /dev/sdd
> Phase 1 - find and verify superblock...
> xfs_repair: error - read only 0 of 512 bytes

stracing those to see where it is failing to read might be useful.

It seems that your device has somehow shrunk out from under your fs.

-Eric

> 
> 'testdisk' does find the filesystem as XFS 4 and i created a 1.5TB dump of it to another hdd.
> 
> Is there any way I can fix this? - Except restroring from backup? Because this IS my backup!
> see ubuntuforums.org/showthread.php?t=1910962 for more details…
> 
> 
> Any help is appreciated!
> 
> Thanks in advance
> Chris
> _______________________________________________
> 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

Re: How to fix bad superblock or xfs_repair: error - read only 0 of 512 bytes

[Christian Kildau]

[-- Attachment #1: Type: text/plain, Size: 32 bytes --]

Sorry, heres the right strace:


[-- Attachment #2: xfs_check.strace --]
[-- Type: application/octet-stream, Size: 3435 bytes --]

execve("/usr/sbin/xfs_check", ["xfs_check", "/dev/sde"], [/* 20 vars */]) = 0
brk(0)                                  = 0x13b9000
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f3935828000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY)      = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=23783, ...}) = 0
mmap(NULL, 23783, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f3935822000
close(3)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0 \24\2\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1689912, ...}) = 0
mmap(NULL, 3806024, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f3935268000
mprotect(0x7f39353ff000, 2097152, PROT_NONE) = 0
mmap(0x7f39355ff000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x197000) = 0x7f39355ff000
mmap(0x7f3935604000, 21320, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f3935604000
close(3)                                = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f3935821000
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f393581f000
arch_prctl(ARCH_SET_FS, 0x7f393581f720) = 0
mprotect(0x7f39355ff000, 16384, PROT_READ) = 0
mprotect(0x619000, 4096, PROT_READ)     = 0
mprotect(0x7f393582a000, 4096, PROT_READ) = 0
munmap(0x7f3935822000, 23783)           = 0
getpid()                                = 11387
rt_sigaction(SIGCHLD, {0x40f0e0, ~[RTMIN RT_1], SA_RESTORER, 0x7f393529e430}, NULL, 8) = 0
geteuid()                               = 0
brk(0)                                  = 0x13b9000
brk(0x13da000)                          = 0x13da000
getppid()                               = 11386
stat("/home/mrkofee", {st_mode=S_IFDIR|S_ISGID|0770, st_size=4096, ...}) = 0
stat(".", {st_mode=S_IFDIR|S_ISGID|0770, st_size=4096, ...}) = 0
open("/usr/sbin/xfs_check", O_RDONLY)   = 3
fcntl(3, F_DUPFD, 10)                   = 10
close(3)                                = 0
fcntl(10, F_SETFD, FD_CLOEXEC)          = 0
rt_sigaction(SIGINT, NULL, {SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGINT, {0x40f0e0, ~[RTMIN RT_1], SA_RESTORER, 0x7f393529e430}, NULL, 8) = 0
rt_sigaction(SIGQUIT, NULL, {SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGQUIT, {SIG_DFL, ~[RTMIN RT_1], SA_RESTORER, 0x7f393529e430}, NULL, 8) = 0
rt_sigaction(SIGTERM, NULL, {SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGTERM, {SIG_DFL, ~[RTMIN RT_1], SA_RESTORER, 0x7f393529e430}, NULL, 8) = 0
read(10, "#!/bin/sh -f\n#\n# Copyright (c) 2"..., 8192) = 698
stat("/usr/local/sbin/xfs_db", 0x7fff67038140) = -1 ENOENT (No such file or directory)
stat("/usr/local/bin/xfs_db", 0x7fff67038140) = -1 ENOENT (No such file or directory)
stat("/usr/sbin/xfs_db", {st_mode=S_IFREG|0755, st_size=438344, ...}) = 0
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f393581f9f0) = 11388
wait4(-1, xfs_check: error - read only 0 of 512 bytes
[{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0, NULL) = 11388
--- SIGCHLD (Child exited) @ 0 (0) ---
rt_sigreturn(0x11)                      = 11388
exit_group(0)                           = ?

[-- Attachment #3: xfs_repair.strace --]
[-- Type: application/octet-stream, Size: 7959 bytes --]

execve("/sbin/xfs_repair", ["xfs_repair", "/dev/sde"], [/* 20 vars */]) = 0
brk(0)                                  = 0x846000
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fe7a0405000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY)      = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=23783, ...}) = 0
mmap(NULL, 23783, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fe7a03ff000
close(3)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
open("/lib/x86_64-linux-gnu/libuuid.so.1", O_RDONLY) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0p\25\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=18896, ...}) = 0
mmap(NULL, 2113944, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fe79ffe2000
mprotect(0x7fe79ffe6000, 2093056, PROT_NONE) = 0
mmap(0x7fe7a01e5000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x3000) = 0x7fe7a01e5000
close(3)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
open("/lib/x86_64-linux-gnu/librt.so.1", O_RDONLY) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\200!\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=31752, ...}) = 0
mmap(NULL, 2128984, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fe79fdda000
mprotect(0x7fe79fde1000, 2093056, PROT_NONE) = 0
mmap(0x7fe79ffe0000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x6000) = 0x7fe79ffe0000
close(3)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
open("/lib/x86_64-linux-gnu/libpthread.so.0", O_RDONLY) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240k\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=135217, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fe7a03fe000
mmap(NULL, 2212888, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fe79fbbd000
mprotect(0x7fe79fbd5000, 2093056, PROT_NONE) = 0
mmap(0x7fe79fdd4000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x17000) = 0x7fe79fdd4000
mmap(0x7fe79fdd6000, 13336, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fe79fdd6000
close(3)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0 \24\2\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1689912, ...}) = 0
mmap(NULL, 3806024, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fe79f81b000
mprotect(0x7fe79f9b2000, 2097152, PROT_NONE) = 0
mmap(0x7fe79fbb2000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x197000) = 0x7fe79fbb2000
mmap(0x7fe79fbb7000, 21320, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fe79fbb7000
close(3)                                = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fe7a03fd000
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fe7a03fb000
arch_prctl(ARCH_SET_FS, 0x7fe7a03fb760) = 0
mprotect(0x7fe79fbb2000, 16384, PROT_READ) = 0
mprotect(0x7fe79fdd4000, 4096, PROT_READ) = 0
mprotect(0x7fe79ffe0000, 4096, PROT_READ) = 0
mprotect(0x7fe7a01e5000, 4096, PROT_READ) = 0
mprotect(0x671000, 4096, PROT_READ)     = 0
mprotect(0x7fe7a0407000, 4096, PROT_READ) = 0
munmap(0x7fe7a03ff000, 23783)           = 0
set_tid_address(0x7fe7a03fba30)         = 11699
set_robust_list(0x7fe7a03fba40, 0x18)   = 0
futex(0x7fff0d90d54c, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 1, NULL, 7fe7a03fb760) = -1 EAGAIN (Resource temporarily unavailable)
rt_sigaction(SIGRTMIN, {0x7fe79fbc3680, [], SA_RESTORER|SA_SIGINFO, 0x7fe79fbccc10}, NULL, 8) = 0
rt_sigaction(SIGRT_1, {0x7fe79fbc3710, [], SA_RESTORER|SA_RESTART|SA_SIGINFO, 0x7fe79fbccc10}, NULL, 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0
getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0
brk(0)                                  = 0x846000
brk(0x867000)                           = 0x867000
open("/usr/lib/locale/locale-archive", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=2919792, ...}) = 0
mmap(NULL, 2919792, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fe79f552000
close(3)                                = 0
getcwd("/home/mrkofee", 4096)           = 14
stat("/dev/sde", {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 64), ...}) = 0
stat("/dev/sde", {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 64), ...}) = 0
ustat(0x840, 0x7fff0d90bf80)            = -1 EINVAL (Invalid argument)
open("/dev/sde", O_RDONLY)              = 3
stat("/dev/sde", {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 64), ...}) = 0
stat("/dev/sde", {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 64), ...}) = 0
ustat(0x840, 0x7fff0d90bf80)            = -1 EINVAL (Invalid argument)
open("/dev/sde", O_RDWR|O_EXCL|O_DIRECT) = 4
fstat(4, {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 64), ...}) = 0
fstat(4, {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 64), ...}) = 0
ioctl(4, BLKGETSIZE64, 0x7fff0d90c0f0)  = 0
ioctl(4, BLKSSZGET, 0x6732e0)           = 0
chdir("/home/mrkofee")                  = 0
brk(0x888000)                           = 0x888000
close(3)                                = 0
getrlimit(RLIMIT_FSIZE, {rlim_cur=RLIM_INFINITY, rlim_max=RLIM_INFINITY}) = 0
time(NULL)                              = 1327315350
time(NULL)                              = 1327315350
open("/usr/share/locale/locale.alias", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=2570, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fe79f551000
read(3, "# Locale name alias data base.\n#"..., 4096) = 2570
read(3, "", 4096)                       = 0
close(3)                                = 0
munmap(0x7fe79f551000, 4096)            = 0
open("/usr/share/locale/en_US/LC_MESSAGES/xfsprogs.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/en/LC_MESSAGES/xfsprogs.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale-langpack/en_US/LC_MESSAGES/xfsprogs.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale-langpack/en/LC_MESSAGES/xfsprogs.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
write(2, "Phase 1 - find and verify superb"..., 40Phase 1 - find and verify superblock...
) = 40
mmap(NULL, 528384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fe79f4d1000
mmap(NULL, 528384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fe79f450000
lseek(4, 0, SEEK_SET)                   = 0
read(4, "XFSB\0\0\20\0\0\0\0\0\25\325\17f\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 524288) = 524288
munmap(0x7fe79f450000, 528384)          = 0
brk(0x8be000)                           = 0x8be000
lseek(4, 375075479552, SEEK_SET)        = 375075479552
read(4, "XFSB\0\0\20\0\0\0\0\0\25\325\17f\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 131072) = 131072
lseek(4, 750150959104, SEEK_SET)        = 750150959104
read(4, "XFSB\0\0\20\0\0\0\0\0\25\325\17f\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 131072) = 131072
lseek(4, 1125226438656, SEEK_SET)       = 1125226438656
read(4, "XFSB\0\0\20\0\0\0\0\0\25\325\17f\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 131072) = 131072
munmap(0x7fe79f4d1000, 528384)          = 0
time(NULL)                              = 1327315350
pread(4, "XFSB\0\0\20\0\0\0\0\0\25\325\17f\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 32768, 0) = 32768
pread(4, "", 512, 1500301909504)        = 0
write(2, "xfs_repair: error - read only 0 "..., 45xfs_repair: error - read only 0 of 512 bytes
) = 45
exit_group(1)                           = ?

[-- Attachment #4: Type: text/plain, Size: 1642 bytes --]



All other output was correct!



On Jan 23, 2012, at 5:31 AM, Dave Chinner wrote:

> On Sat, Jan 21, 2012 at 11:29:15AM +0100, Christian Kildau wrote:
>> Sorry if this message appears twice!
>> 
>> 
>> 
>> Hello,
>> 
>> I'm having some very serious issues with XFS after upgrading from a
>> Linux Distro running Ubuntu 2.6.32 to 3.2.
>> 
>> It seems like my filesystems are damaged after attaching them to a
>> Linux 3.2 server. I am also no longer able to mount the hdd on the old
>> server that is still running 2.6.32!
> 
> I take it that you are using external storage of some kind? Can you
> describe it?
> 
>> (I created the xfs filesystem on the entire hdd, not on a partition,
>> so /dev/sdd is not a typo)
>> 
>> $ sudo mount -t xfs /dev/sdd /media/
>> mount: /dev/sdd: can't read superblock
>> (dmesg)
>> [236659.912663] attempt to access beyond end of device
>> [236659.912667] sdd: rw=32, want=2930277168, limit=2930275055
>> [236659.912670] XFS (sdd): last sector read failed
> 
> So XFS has asked to read 2113 sectors beyond the size of the device
> that the kernel is reporting. What is the output of
> /proc/partitions?
> 
>> $ sudo xfs_check /dev/sdd
>> xfs_check: error - read only 0 of 512 bytes
>> 
>> $ sudo xfs_repair /dev/sdd
>> Phase 1 - find and verify superblock...
>> xfs_repair: error - read only 0 of 512 bytes
> 
> So both buffered and direct IO to the first block in the block
> device are failing. I'd say your problems have nothing to do with
> XFS. However, can you strace them and find out what the error that
> is occuring actually is?
> 
> Cheers,
> 
> Dave.
> -- 
> Dave Chinner
> david@fromorbit.com


[-- Attachment #5: Type: text/plain, Size: 121 bytes --]

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: How to fix bad superblock or xfs_repair: error - read only 0 of 512 bytes

[Christian Kildau]

[-- Attachment #1: Type: text/plain, Size: 2285 bytes --]

On Jan 23, 2012, at 5:31 AM, Dave Chinner wrote:

> On Sat, Jan 21, 2012 at 11:29:15AM +0100, Christian Kildau wrote:
>> Sorry if this message appears twice!
>> 
>> 
>> 
>> Hello,
>> 
>> I'm having some very serious issues with XFS after upgrading from a
>> Linux Distro running Ubuntu 2.6.32 to 3.2.
>> 
>> It seems like my filesystems are damaged after attaching them to a
>> Linux 3.2 server. I am also no longer able to mount the hdd on the old
>> server that is still running 2.6.32!
> 
> I take it that you are using external storage of some kind? Can you
> describe it?

This hdd is connected via e-sata, but it doesn't make any difference if I directly connect it internally via sata.
Also it doesn't make any difference if I connect it back to the 'old' server

> 
>> (I created the xfs filesystem on the entire hdd, not on a partition,
>> so /dev/sdd is not a typo)
>> 
>> $ sudo mount -t xfs /dev/sdd /media/
>> mount: /dev/sdd: can't read superblock
>> (dmesg)
>> [236659.912663] attempt to access beyond end of device
>> [236659.912667] sdd: rw=32, want=2930277168, limit=2930275055
>> [236659.912670] XFS (sdd): last sector read failed
> 
> So XFS has asked to read 2113 sectors beyond the size of the device
> that the kernel is reporting. What is the output of
> /proc/partitions?

$ grep sdd /proc/partitions 
   8       64 1465137527 sdd

> 
>> $ sudo xfs_check /dev/sdd
>> xfs_check: error - read only 0 of 512 bytes
>> 
>> $ sudo xfs_repair /dev/sdd
>> Phase 1 - find and verify superblock...
>> xfs_repair: error - read only 0 of 512 bytes
> 
> So both buffered and direct IO to the first block in the block
> device are failing. I'd say your problems have nothing to do with
> XFS. However, can you strace them and find out what the error that
> is occuring actually is?

Strace is giving me:
wait4(-1, xfs_check: /dev/sdd is not a valid XFS filesystem (unexpected SB magic number 0x00000000)
xfs_check: WARNING - filesystem uses v1 dirs,limited functionality provided.
xfs_check: read failed: Invalid argument
cache_node_purge: refcount was 1, not zero (node=0x21ecef0)
xfs_check: cannot read root inode (22)
bad superblock magic number 0, giving up

I attached the entire strace logs to this email.

[-- Attachment #2: xfs_check.strace --]
[-- Type: application/octet-stream, Size: 3712 bytes --]

execve("/usr/sbin/xfs_check", ["xfs_check", "/dev/sdd"], [/* 21 vars */]) = 0
brk(0)                                  = 0x734000
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f19a4a05000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY)      = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=23783, ...}) = 0
mmap(NULL, 23783, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f19a49ff000
close(3)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0 \24\2\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1689912, ...}) = 0
mmap(NULL, 3806024, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f19a4445000
mprotect(0x7f19a45dc000, 2097152, PROT_NONE) = 0
mmap(0x7f19a47dc000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x197000) = 0x7f19a47dc000
mmap(0x7f19a47e1000, 21320, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f19a47e1000
close(3)                                = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f19a49fe000
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f19a49fc000
arch_prctl(ARCH_SET_FS, 0x7f19a49fc720) = 0
mprotect(0x7f19a47dc000, 16384, PROT_READ) = 0
mprotect(0x619000, 4096, PROT_READ)     = 0
mprotect(0x7f19a4a07000, 4096, PROT_READ) = 0
munmap(0x7f19a49ff000, 23783)           = 0
getpid()                                = 28928
rt_sigaction(SIGCHLD, {0x40f0e0, ~[RTMIN RT_1], SA_RESTORER, 0x7f19a447b430}, NULL, 8) = 0
geteuid()                               = 0
brk(0)                                  = 0x734000
brk(0x755000)                           = 0x755000
getppid()                               = 28927
stat("/root", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0
stat(".", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0
open("/usr/sbin/xfs_check", O_RDONLY)   = 3
fcntl(3, F_DUPFD, 10)                   = 10
close(3)                                = 0
fcntl(10, F_SETFD, FD_CLOEXEC)          = 0
rt_sigaction(SIGINT, NULL, {SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGINT, {0x40f0e0, ~[RTMIN RT_1], SA_RESTORER, 0x7f19a447b430}, NULL, 8) = 0
rt_sigaction(SIGQUIT, NULL, {SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGQUIT, {SIG_DFL, ~[RTMIN RT_1], SA_RESTORER, 0x7f19a447b430}, NULL, 8) = 0
rt_sigaction(SIGTERM, NULL, {SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGTERM, {SIG_DFL, ~[RTMIN RT_1], SA_RESTORER, 0x7f19a447b430}, NULL, 8) = 0
read(10, "#!/bin/sh -f\n#\n# Copyright (c) 2"..., 8192) = 698
stat("/usr/local/sbin/xfs_db", 0x7fffa2d5d780) = -1 ENOENT (No such file or directory)
stat("/usr/local/bin/xfs_db", 0x7fffa2d5d780) = -1 ENOENT (No such file or directory)
stat("/usr/sbin/xfs_db", {st_mode=S_IFREG|0755, st_size=438344, ...}) = 0
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f19a49fc9f0) = 28929
wait4(-1, xfs_check: /dev/sdd is not a valid XFS filesystem (unexpected SB magic number 0x00000000)
xfs_check: WARNING - filesystem uses v1 dirs,limited functionality provided.
xfs_check: read failed: Invalid argument
cache_node_purge: refcount was 1, not zero (node=0x21ecef0)
xfs_check: cannot read root inode (22)
bad superblock magic number 0, giving up
[{WIFEXITED(s) && WEXITSTATUS(s) == 3}], 0, NULL) = 28929
--- SIGCHLD (Child exited) @ 0 (0) ---
rt_sigreturn(0x11)                      = 28929
exit_group(3)                           = ?

[-- Attachment #3: xfs_repair.strace --]
[-- Type: application/octet-stream, Size: 7958 bytes --]

execve("/sbin/xfs_repair", ["xfs_repair", "/dev/sde"], [/* 21 vars */]) = 0
brk(0)                                  = 0xcf5000
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f4dc82c5000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY)      = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=23783, ...}) = 0
mmap(NULL, 23783, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f4dc82bf000
close(3)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
open("/lib/x86_64-linux-gnu/libuuid.so.1", O_RDONLY) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0p\25\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=18896, ...}) = 0
mmap(NULL, 2113944, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f4dc7ea2000
mprotect(0x7f4dc7ea6000, 2093056, PROT_NONE) = 0
mmap(0x7f4dc80a5000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x3000) = 0x7f4dc80a5000
close(3)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
open("/lib/x86_64-linux-gnu/librt.so.1", O_RDONLY) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\200!\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=31752, ...}) = 0
mmap(NULL, 2128984, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f4dc7c9a000
mprotect(0x7f4dc7ca1000, 2093056, PROT_NONE) = 0
mmap(0x7f4dc7ea0000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x6000) = 0x7f4dc7ea0000
close(3)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
open("/lib/x86_64-linux-gnu/libpthread.so.0", O_RDONLY) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240k\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=135217, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f4dc82be000
mmap(NULL, 2212888, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f4dc7a7d000
mprotect(0x7f4dc7a95000, 2093056, PROT_NONE) = 0
mmap(0x7f4dc7c94000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x17000) = 0x7f4dc7c94000
mmap(0x7f4dc7c96000, 13336, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f4dc7c96000
close(3)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0 \24\2\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1689912, ...}) = 0
mmap(NULL, 3806024, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f4dc76db000
mprotect(0x7f4dc7872000, 2097152, PROT_NONE) = 0
mmap(0x7f4dc7a72000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x197000) = 0x7f4dc7a72000
mmap(0x7f4dc7a77000, 21320, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f4dc7a77000
close(3)                                = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f4dc82bd000
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f4dc82bb000
arch_prctl(ARCH_SET_FS, 0x7f4dc82bb760) = 0
mprotect(0x7f4dc7a72000, 16384, PROT_READ) = 0
mprotect(0x7f4dc7c94000, 4096, PROT_READ) = 0
mprotect(0x7f4dc7ea0000, 4096, PROT_READ) = 0
mprotect(0x7f4dc80a5000, 4096, PROT_READ) = 0
mprotect(0x671000, 4096, PROT_READ)     = 0
mprotect(0x7f4dc82c7000, 4096, PROT_READ) = 0
munmap(0x7f4dc82bf000, 23783)           = 0
set_tid_address(0x7f4dc82bba30)         = 28633
set_robust_list(0x7f4dc82bba40, 0x18)   = 0
futex(0x7fffb24a3f1c, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 1, NULL, 7f4dc82bb760) = -1 EAGAIN (Resource temporarily unavailable)
rt_sigaction(SIGRTMIN, {0x7f4dc7a83680, [], SA_RESTORER|SA_SIGINFO, 0x7f4dc7a8cc10}, NULL, 8) = 0
rt_sigaction(SIGRT_1, {0x7f4dc7a83710, [], SA_RESTORER|SA_RESTART|SA_SIGINFO, 0x7f4dc7a8cc10}, NULL, 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0
getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0
brk(0)                                  = 0xcf5000
brk(0xd16000)                           = 0xd16000
open("/usr/lib/locale/locale-archive", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=2919792, ...}) = 0
mmap(NULL, 2919792, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f4dc7412000
close(3)                                = 0
getcwd("/root", 4096)                   = 6
stat("/dev/sde", {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 64), ...}) = 0
stat("/dev/sde", {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 64), ...}) = 0
ustat(0x840, 0x7fffb24a2950)            = -1 EINVAL (Invalid argument)
open("/dev/sde", O_RDONLY)              = 3
stat("/dev/sde", {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 64), ...}) = 0
stat("/dev/sde", {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 64), ...}) = 0
ustat(0x840, 0x7fffb24a2950)            = -1 EINVAL (Invalid argument)
open("/dev/sde", O_RDWR|O_EXCL|O_DIRECT) = 4
fstat(4, {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 64), ...}) = 0
fstat(4, {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 64), ...}) = 0
ioctl(4, BLKGETSIZE64, 0x7fffb24a2ac0)  = 0
ioctl(4, BLKSSZGET, 0x6732e0)           = 0
chdir("/root")                          = 0
brk(0xd37000)                           = 0xd37000
close(3)                                = 0
getrlimit(RLIMIT_FSIZE, {rlim_cur=RLIM_INFINITY, rlim_max=RLIM_INFINITY}) = 0
time(NULL)                              = 1327310356
time(NULL)                              = 1327310356
open("/usr/share/locale/locale.alias", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=2570, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f4dc7411000
read(3, "# Locale name alias data base.\n#"..., 4096) = 2570
read(3, "", 4096)                       = 0
close(3)                                = 0
munmap(0x7f4dc7411000, 4096)            = 0
open("/usr/share/locale/en_US/LC_MESSAGES/xfsprogs.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/en/LC_MESSAGES/xfsprogs.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale-langpack/en_US/LC_MESSAGES/xfsprogs.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale-langpack/en/LC_MESSAGES/xfsprogs.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
write(2, "Phase 1 - find and verify superb"..., 40Phase 1 - find and verify superblock...
) = 40
mmap(NULL, 528384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f4dc7391000
mmap(NULL, 528384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f4dc7310000
lseek(4, 0, SEEK_SET)                   = 0
read(4, "XFSB\0\0\20\0\0\0\0\0\25\325\17f\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 524288) = 524288
munmap(0x7f4dc7310000, 528384)          = 0
brk(0xd6d000)                           = 0xd6d000
lseek(4, 375075479552, SEEK_SET)        = 375075479552
read(4, "XFSB\0\0\20\0\0\0\0\0\25\325\17f\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 131072) = 131072
lseek(4, 750150959104, SEEK_SET)        = 750150959104
read(4, "XFSB\0\0\20\0\0\0\0\0\25\325\17f\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 131072) = 131072
lseek(4, 1125226438656, SEEK_SET)       = 1125226438656
read(4, "XFSB\0\0\20\0\0\0\0\0\25\325\17f\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 131072) = 131072
munmap(0x7f4dc7391000, 528384)          = 0
time(NULL)                              = 1327310357
pread(4, "XFSB\0\0\20\0\0\0\0\0\25\325\17f\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 32768, 0) = 32768
pread(4, "", 512, 1500301909504)        = 0
write(2, "xfs_repair: error - read only 0 "..., 45xfs_repair: error - read only 0 of 512 bytes
) = 45
exit_group(1)                           = ?

[-- Attachment #4: Type: text/plain, Size: 87 bytes --]



Do you have any idea what has caused this or how to fix it?

Thanks in advance!
Chris

[-- Attachment #5: Type: text/plain, Size: 121 bytes --]

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: How to fix bad superblock or xfs_repair: error - read only 0 of 512 bytes

[Dave Chinner]

On Sat, Jan 21, 2012 at 11:29:15AM +0100, Christian Kildau wrote:
> Sorry if this message appears twice!
> 
> 
> 
> Hello,
> 
> I'm having some very serious issues with XFS after upgrading from a
> Linux Distro running Ubuntu 2.6.32 to 3.2.
> 
> It seems like my filesystems are damaged after attaching them to a
> Linux 3.2 server. I am also no longer able to mount the hdd on the old
> server that is still running 2.6.32!

I take it that you are using external storage of some kind? Can you
describe it?

> (I created the xfs filesystem on the entire hdd, not on a partition,
> so /dev/sdd is not a typo)
> 
> $ sudo mount -t xfs /dev/sdd /media/
> mount: /dev/sdd: can't read superblock
> (dmesg)
> [236659.912663] attempt to access beyond end of device
> [236659.912667] sdd: rw=32, want=2930277168, limit=2930275055
> [236659.912670] XFS (sdd): last sector read failed

So XFS has asked to read 2113 sectors beyond the size of the device
that the kernel is reporting. What is the output of
/proc/partitions?

> $ sudo xfs_check /dev/sdd
> xfs_check: error - read only 0 of 512 bytes
> 
> $ sudo xfs_repair /dev/sdd
> Phase 1 - find and verify superblock...
> xfs_repair: error - read only 0 of 512 bytes

So both buffered and direct IO to the first block in the block
device are failing. I'd say your problems have nothing to do with
XFS. However, can you strace them and find out what the error that
is occuring actually is?

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

How to fix bad superblock or xfs_repair: error - read only 0 of 512 bytes

[Christian Kildau]

Sorry if this message appears twice!



Hello,

I'm having some very serious issues with XFS after upgrading from a
Linux Distro running Ubuntu 2.6.32 to 3.2.

It seems like my filesystems are damaged after attaching them to a
Linux 3.2 server. I am also no longer able to mount the hdd on the old
server that is still running 2.6.32!


(I created the xfs filesystem on the entire hdd, not on a partition,
so /dev/sdd is not a typo)

$ sudo mount -t xfs /dev/sdd /media/
mount: /dev/sdd: can't read superblock
(dmesg)
[236659.912663] attempt to access beyond end of device
[236659.912667] sdd: rw=32, want=2930277168, limit=2930275055
[236659.912670] XFS (sdd): last sector read failed

$ sudo xfs_check /dev/sdd
xfs_check: error - read only 0 of 512 bytes

$ sudo xfs_repair /dev/sdd
Phase 1 - find and verify superblock...
xfs_repair: error - read only 0 of 512 bytes


'testdisk' does find the filesystem as XFS 4 and i created a 1.5TB
dump of it to another hdd.

Is there any way I can fix this? - Except restroring from backup?
Because this IS my backup!
see ubuntuforums.org/showthread.php?t=1910962 for more details…


Any help is appreciated!

Thanks in advance
Chris

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

How to fix bad superblock or xfs_repair: error - read only 0 of 512 bytes

[Christian Kildau]

Hello,

I'm having some very serious issues with XFS after upgrading from a Linux Distro running Ubuntu 2.6.32 to 3.2.

It seems like my filesystems are damaged after attaching them to a Linux 3.2 server. I am also no longer able to mount the hdd on the old server that is still running 2.6.32!

'test disk' does find the filesystem as XFS 4 and i created a 1.5TB dump of it to another hdd.

(I created the xfs filesystem on the entire hdd, not on a partition, so /dev/sdd is not a typo)

$ sudo mount -t xfs /dev/sdd /media/
mount: /dev/sdd: can't read superblock
(dmesg)
[236659.912663] attempt to access beyond end of device
[236659.912667] sdd: rw=32, want=2930277168, limit=2930275055
[236659.912670] XFS (sdd): last sector read failed

$ sudo xfs_check /dev/sdd
xfs_check: error - read only 0 of 512 bytes

$ sudo xfs_repair /dev/sdd
Phase 1 - find and verify superblock...
xfs_repair: error - read only 0 of 512 bytes


'testdisk' does find the filesystem as XFS 4 and i created a 1.5TB dump of it to another hdd.

Is there any way I can fix this? - Except restroring from backup? Because this IS my backup!
see ubuntuforums.org/showthread.php?t=1910962 for more details…


Any help is appreciated!

Thanks in advance
Chris
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs