Linked by theosib on Sun 14th Feb 2010 10:45 UTC
Linux

Recently, I bought a pair of those new Western Digital Caviar Green drives. These new drives represent a transitional point from 512-byte sectors to 4096-byte sectors. A number of articles have been published recently about this, explaining the benefits and some of the challenges that we'll be facing during this transition. Reportedly, Linux should unaffected by some of the pitfalls of this transition, but my own experimentation has shown that Linux is just as vulnerable to the potential performance impact as Windows XP. Despite this issue being known about for a long time, basic Linux tools for partitioning and formatting drives have not caught up.

Thread beginning with comment 409281
To read all comments associated with this story, please click here.
fdisk and DOS-compatiple partitions
by Lennie on Sun 14th Feb 2010 11:06 UTC
Lennie
Member since:
2007-09-22

It's not so much Linux, it's the DOS-compatible partition that fdisk creates.

If you don't need DOS-compatiblility, you wouldn't have a problem.

It's a DOS/Windows-compatibility thing you are trying to attribute to Linux. DOS/Windows has a problem, Linux just tries to be compatible.

As you said, parted does it just fine.

Edited 2010-02-14 11:09 UTC

Reply Score: 11

bralkein Member since:
2006-12-20

The fdisk man page (on my machine at least) contains a lengthy warning about how fdisk will quite happily create some pretty dodgy partition layouts and it recommends parted for doing anything even remotely unusual. I guess this falls into that category.

All the major noob-friendly distros use gparted for doing the partition editing, don't they? Will that protect users from these kinds of problem, then?

Reply Parent Score: 4

WereCatf Member since:
2006-02-15

All the major noob-friendly distros use gparted for doing the partition editing, don't they? Will that protect users from these kinds of problem, then?

I do consider Mandriva to be pretty newbie-friendly all in all; it's clear, consistent, and provides an extensive selection of documentation and loads of online help if needed. Also, it's really stable and has excellent control center utility.

But alas, Mandriva doesn't actually use gparted. They use some sort of a tool of their own which apparently uses libparted as its backend. As far as I know quite a few distros actually do it that way. But as the article states, you seemingly have to use "--align optimal" option which does the right thing. It doesn't automatically align the partitions properly without that. And I have no idea if those custom partitioning tools employed by various distros pass such an option to libparted. If they don't then that'll be a very important issue to fix immediately.

I'd actually prefer if distros rolled out an update of some sort which will check the currently installed system and its partitioning scheme and warn if they are misaligned and would provide a way of fixing it; not everyone re-installs their system all the time and as such could be using misaligned partitions for years before next re-install.

Reply Parent Score: 3

akajeff Member since:
2010-02-14

So, since you're using Linux, wouldn't it behoove you to use the GPT (GUID Parition Table) scheme which handles, by design, the new block size?

ref: http://en.wikipedia.org/wiki/GUID_Partition_Table

Reply Parent Score: 2

bralkein Member since:
2006-12-20

Well apart from anything, fdisk doesn't support GPT. Parted does, but as he said, you can get parted to automatically solve the problem anyway.

The problem as TFA describes it is that a bunch of the tools & tutorials out there today will give you bad results if you use them with the new block size. They will probably give you bad results if you use them with GPT, too.

Edited 2010-02-14 17:57 UTC

Reply Parent Score: 2

Brendan Member since:
2005-11-16

Hi,

It's a DOS/Windows-compatibility thing you are trying to attribute to Linux. DOS/Windows has a problem, Linux just tries to be compatible.


No.

Very old disk drives used "CHS" (Cylinders, Heads, Sectors) instead of LBA. Due to limitations this didn't work for drives larger than about 500 MiB, so the industry shifted to LBA; and created a CHS->LBA translation scheme.

Due to BIOS limits, this CHS->LBA translation scheme usually uses "63 sectors per track", which is the highest number of sectors per track that the old BIOS disk interface can handle.

For performance reasons OSs make partitions that start/end on track boundaries (having a few sectors at the start or end of a partition that are on a track by themselves causes more disk head movement).

Basically what I'm saying is that the problem wasn't caused by *any* OS. The problem is caused by 30 years of backward compatibility (and the lack of foresight, from BIOS, disk and OS designers).

The ironic part is that the original IBM design supported floppy disks and hard drives with different sector sizes. It's unfortunate that this aspect of the original design was lost, and unfortunate that these new hard drives need to emulate 512-byte sectors to begin with.

-Brendan

Reply Parent Score: 11