Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.hardware > #1044 > unrolled thread

Re: suddenly shrunk HDD?!

Back to article view | Back to comp.os.linux.hardware

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: suddenly shrunk HDD?! Ivan Shmakov <oneingray@gmail.com> - 2012-02-07 16:51 +0700
    Re: [RESOLVED] suddenly shrunk HDD?! Ivan Shmakov <oneingray@gmail.com> - 2012-02-07 17:18 +0700

#1044 — Re: suddenly shrunk HDD?!

>>>>> Aragorn  <stryder@telenet.be.invalid> writes:
>>>>> Ivan Shmakov conveyed the following to alt.os.linux.debian...
>>>>> Aragorn  <stryder@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

[toc] | [next] | [standalone]

#1045 — Re: [RESOLVED] suddenly shrunk HDD?!

>>>>> Ivan Shmakov <oneingray@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
...

# 

-- 
FSF associate member #7257

[toc] | [prev] | [standalone]

Back to top | Article view | comp.os.linux.hardware

csiph-web