Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Re: suddenly shrunk HDD?!
11 views
Skip to first unread message
Ivan Shmakov
Feb 7, 2012, 4:51:26 AM2/7/12
to
>>>>> Aragorn <str...@telenet.be.invalid> writes:
>>>>> Ivan Shmakov conveyed the following to alt.os.linux.debian...
>>>>> Aragorn <str...@telenet.be.invalid> writes:
>>>>> Ivan Shmakov conveyed the following to alt.os.linux.debian...
[...]
>> And is there a newsgroup for questions related to hard disks, etc.,
>> anyway?]
> Not for hard disks specifically, but comp.os.linux.hardware might
> prove a useful resource on hardware information. ;-)
ACK, cross-posted there as well. As the question does no longer
seem Debian-specific, I've also dropped news:alt.os.linux.debian
from Followup-To:.
[...]
>>>> Now, it seems that the problem is worse than that. As of
>>>> 2012-01-07, # hdparm -I has claimed that the HDD in question had
>>>> 1953525168 sectors. Now, it's only 1953523055 (some 1.03 MiB
>>>> shorter)!
>>>> Any ideas on what's going on?
>>> Wild guess: the hard disk has found and remapped more bad sectors?
>>> In that case, it would be an indication that you had better start
>>> looking for a replacement disk, because quite frankly, this one
>>> appears to have started on a journey to the deep South.
>> I doubt so, since that'd result in "unremappable" bad sectors, not
>> in the media size reduction. (I've had the opportunity to take a
>> look at the SMART data, but forgot to do that.)
>> In news:fido7.su.hardw.other, it was suggested that this could
>> somehow be related to the mainboard's integrated SATA controller, so
>> I'm going to try an "external" one.
> I don't really see how the SATA controller could be reporting
> inconsistent sector mappings. I'd rather suspect this to be
> something that the hard disk itself would do.
I don't know neither how nor why, but the BIOS seem to be able
to program the HDD just like that. Consider, e. g.:
--cut: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/380138 --
c) Virtual BIOS solutions - like GigaByte motherboards use
This is absolutely CRITICAL. When the hd is unlocked and fully used
new GigaByte boards tend to write 1.5 MB at the end of IDE or SATA
drives in legacy mode as BIOS backup. Then HPA is activated, every
OS has to respect this otherwise it will definitely overwrite data.
That's usally not directly visable for the user, but it definitely
happens. Depending of the filesystem used for the partition using
that last mb will immediately kill data or it will take time till it
is filled, but corruption is inevitable.
--cut: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/380138 --
--cut: http://forum.giga-byte.co.uk/index.php/topic,1069.0.html --
Unfortunately I Enabled this option in BIOS (Backup BIOS image to
HDD) and after that I lost data on first disc Embarrassed . Thanks
for this 'useful' option and any warnig in this option in BIOS :/
--cut: http://forum.giga-byte.co.uk/index.php/topic,1069.0.html --
I've also tried attaching the HDD in question to another system
(via an USB SATA host), but it still fails to access data beyond
the 1953523055'th sector.
The question is: how do I revert the HDD back to its original
1953525168 sectors?
[...]
--
FSF associate member #7257
>>>>> Ivan Shmakov conveyed the following to alt.os.linux.debian...
>>>>> Aragorn <str...@telenet.be.invalid> writes:
>>>>> Ivan Shmakov conveyed the following to alt.os.linux.debian...
[...]
>> And is there a newsgroup for questions related to hard disks, etc.,
>> anyway?]
> Not for hard disks specifically, but comp.os.linux.hardware might
> prove a useful resource on hardware information. ;-)
ACK, cross-posted there as well. As the question does no longer
seem Debian-specific, I've also dropped news:alt.os.linux.debian
from Followup-To:.
[...]
>>>> Now, it seems that the problem is worse than that. As of
>>>> 2012-01-07, # hdparm -I has claimed that the HDD in question had
>>>> 1953525168 sectors. Now, it's only 1953523055 (some 1.03 MiB
>>>> shorter)!
>>>> Any ideas on what's going on?
>>> Wild guess: the hard disk has found and remapped more bad sectors?
>>> In that case, it would be an indication that you had better start
>>> looking for a replacement disk, because quite frankly, this one
>>> appears to have started on a journey to the deep South.
>> I doubt so, since that'd result in "unremappable" bad sectors, not
>> in the media size reduction. (I've had the opportunity to take a
>> look at the SMART data, but forgot to do that.)
>> In news:fido7.su.hardw.other, it was suggested that this could
>> somehow be related to the mainboard's integrated SATA controller, so
>> I'm going to try an "external" one.
> I don't really see how the SATA controller could be reporting
> inconsistent sector mappings. I'd rather suspect this to be
> something that the hard disk itself would do.
I don't know neither how nor why, but the BIOS seem to be able
to program the HDD just like that. Consider, e. g.:
--cut: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/380138 --
c) Virtual BIOS solutions - like GigaByte motherboards use
This is absolutely CRITICAL. When the hd is unlocked and fully used
new GigaByte boards tend to write 1.5 MB at the end of IDE or SATA
drives in legacy mode as BIOS backup. Then HPA is activated, every
OS has to respect this otherwise it will definitely overwrite data.
That's usally not directly visable for the user, but it definitely
happens. Depending of the filesystem used for the partition using
that last mb will immediately kill data or it will take time till it
is filled, but corruption is inevitable.
--cut: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/380138 --
--cut: http://forum.giga-byte.co.uk/index.php/topic,1069.0.html --
Unfortunately I Enabled this option in BIOS (Backup BIOS image to
HDD) and after that I lost data on first disc Embarrassed . Thanks
for this 'useful' option and any warnig in this option in BIOS :/
--cut: http://forum.giga-byte.co.uk/index.php/topic,1069.0.html --
I've also tried attaching the HDD in question to another system
(via an USB SATA host), but it still fails to access data beyond
the 1953523055'th sector.
The question is: how do I revert the HDD back to its original
1953525168 sectors?
[...]
--
FSF associate member #7257
Ivan Shmakov
Feb 7, 2012, 5:18:10 AM2/7/12
to
>>>>> Ivan Shmakov <onei...@gmail.com> writes:
[...]
> The question is: how do I revert the HDD back to its original
> 1953525168 sectors?
So, I've disabled such obnoxiously programmed HPA with
hdparm(8):
# hdparm -N /dev/sdb
/dev/sdb:
max sectors = 1953523055/1953525168, HPA is enabled
# hdparm -N1953525168 /dev/sdb
/dev/sdb:
setting max visible sectors to 1953525168 (temporary)
max sectors = 1953525168/1953525168, HPA is disabled
# hdparm -N /dev/sdb
/dev/sdb:
max sectors = 1953525168/1953525168, HPA is disabled
#
Of course, this hasn't revived the backup GPT table, but at the
very least, both Linux and GNU Parted now recognize the primary
one.
$ dmesg
...
[8613672.086499] Alternate GPT is invalid, using primary GPT.
[8613672.086546] sdb1 sdb2 sdb3 ...
...
$
# parted /dev/sdb unit mib print ok
Error: The backup GPT table is corrupt, but the primary appears OK, so that will
be used.
Model: ATA WDC WD1001FALS-7 (scsi)
Disk /dev/sdb: 953870MiB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number Start End Size File system Name Flags
1 0.02MiB 16.0MiB 16.0MiB biosgrub bios_grub
2 16.0MiB 1024MiB 1008MiB ext3 boot boot
3 1024MiB 16384MiB 15360MiB linux-swap(v1) swap
...
#
[...]
> The question is: how do I revert the HDD back to its original
> 1953525168 sectors?
hdparm(8):
# hdparm -N /dev/sdb
/dev/sdb:
max sectors = 1953523055/1953525168, HPA is enabled
# hdparm -N1953525168 /dev/sdb
/dev/sdb:
setting max visible sectors to 1953525168 (temporary)
max sectors = 1953525168/1953525168, HPA is disabled
# hdparm -N /dev/sdb
/dev/sdb:
max sectors = 1953525168/1953525168, HPA is disabled
#
Of course, this hasn't revived the backup GPT table, but at the
very least, both Linux and GNU Parted now recognize the primary
one.
$ dmesg
...
[8613672.086499] Alternate GPT is invalid, using primary GPT.
[8613672.086546] sdb1 sdb2 sdb3 ...
...
$
# parted /dev/sdb unit mib print ok
Error: The backup GPT table is corrupt, but the primary appears OK, so that will
be used.
Model: ATA WDC WD1001FALS-7 (scsi)
Disk /dev/sdb: 953870MiB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number Start End Size File system Name Flags
1 0.02MiB 16.0MiB 16.0MiB biosgrub bios_grub
2 16.0MiB 1024MiB 1008MiB ext3 boot boot
3 1024MiB 16384MiB 15360MiB linux-swap(v1) swap
...
#
0 new messages