All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@sandeen.net>
To: Christian Kildau <lists@unixhosts.org>
Cc: xfs-oss <xfs@oss.sgi.com>
Subject: Re: How to fix bad superblock or xfs_repair: error - read only 0 of 512 bytes
Date: Tue, 24 Jan 2012 09:57:19 -0600	[thread overview]
Message-ID: <4F1ED4DF.40907@sandeen.net> (raw)
In-Reply-To: <BE48F258-7061-468F-865E-3595D2C28B3B@unixhosts.org>

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

  reply	other threads:[~2012-01-24 15:57 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-21 10:29 How to fix bad superblock or xfs_repair: error - read only 0 of 512 bytes Christian Kildau
2012-01-23  4:31 ` Dave Chinner
2012-01-23  9:23   ` Christian Kildau
2012-01-24  5:04     ` Eric Sandeen
2012-01-24  7:08       ` Christian Kildau
2012-01-24 10:13       ` Christian Kildau
2012-01-24 14:12         ` Roger Willcocks
2012-01-24 15:46           ` Christian Kildau
2012-01-24 15:50             ` Eric Sandeen
2012-01-24 15:52               ` Christian Kildau
2012-01-24 15:57                 ` Eric Sandeen [this message]
2012-01-24 17:25                   ` Roger Willcocks
2012-01-24 18:10                     ` Christian Kildau
2012-01-23 10:43   ` Christian Kildau
  -- strict thread matches above, loose matches on Subject: below --
2019-12-28 11:11 Utpal Bora
2019-12-29  3:15 ` Chris Murphy
2019-12-29  5:58   ` Utpal Bora
2019-12-29  4:43 ` Eric Sandeen
2019-12-29  5:58   ` Utpal Bora
2012-01-21 10:03 Christian Kildau
2012-01-24  4:51 ` Eric Sandeen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4F1ED4DF.40907@sandeen.net \
    --to=sandeen@sandeen.net \
    --cc=lists@unixhosts.org \
    --cc=xfs@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.