[Bug 780093] Re: No way to align 4096/4k-HDDs properly

Phillip Susi psusi at cfl.rr.com
Tue Jan 3 20:10:56 UTC 2012


Parted and gparted already default to aligning the partition start to
1mb, not sector 63.  It sounds like you used fdisk to partition the
drive.  Repartition it with gparted and it should be properly aligned.


** Changed in: gparted (Ubuntu)
       Status: New => Invalid

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to gparted in Ubuntu.
https://bugs.launchpad.net/bugs/780093

Title:
  No way to align 4096/4k-HDDs properly

Status in “gparted” package in Ubuntu:
  Invalid

Bug description:
  Binary package hint: gparted

  I just got myself a WD-2TB-Green 2TB hard disk drive without checking the forums first, implicating that problems from the
  renaissance of computing, e.i. the last decade should not matter any more. I was naive again.

  EARS-Type drives have two annoying "features": for their capacity,
  they are transitional 512-Byte-Sector internally and 4096 Byte sectors
  externally.

  Palimpsest informs me, that the partition is misaligned by 512 bytes -
  which is natural, as the default partition start in linux is 0x63 -
  512 Bytes short. It does not offer further help how to fix this -
  neither does gparted.

  Performance is ugly, like 40 MB/s instead of >=100 MB/s.

  I also learn from the forums again that like some notebook drives back
  in 2007/2008 the EARS is parking every 8 seconds and woken up every
  20s by the kernel when used as system drive. So either fuddling around
  with some obscure WDD-DOS tool or hoping that smartmontool's smartclt
  -s 242 /dev/sdX will save the day.

  Luckily, you only buy large terabyte green-style drives for
  archiving/data server. Raiding those makes it even worse, as there is
  only a message of mkfs.xfs that 4096k-Sectors are not supported by
  XFS. Good that my system is on the nice 40gb cheap and fast intel
  v-series ssd. No parking probs noted here.

  As a result, my 2-disk stripe does 50 MB/sec where it should to in
  between 200-100 MB/sec for large files.

  It is so obvious when copying from a standard-raid0 with 2 samsung blues:
  0 MB for 2 secs, then 300 MB for a sec then nothing again like
  |  |  |  | in gkrellm. Sad.

  And someone clever posted, that for zfs (or zfs-fuse) there is no way even to tell right now how things are there.
  -> ZFS-fuse should be ok though when getting xfs-based large files as containers for devs.

  Please (upstream involved)
  - fix gparted, parted, fdisk, palimpsest to recognize 4k-sector drives and adjust partition boundaries accordingly upon creation - at least add an option to do so
  - fix xfs / mdadm to handle 4k striped arrays
  - Include a "disable head parking" somewhere graphically for newbies.

  I havent looked into btrfs, though.

  To keep blood pressure low ;-) haha - I am not going into the TLER problem, in my case I would rather want my drive to report failed too soon then the other way round - meaning it would be nice, to enable tler. What have they thought at wdd? Greens are not for running a system from - just for backup and mid-performance raids. And they take away the most importand things... sad.
  Next time it will be Korea again :-)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gparted/+bug/780093/+subscriptions




More information about the foundations-bugs mailing list