[CentOS] One disk speed problem [SOLVED], and a question on hdparm

Wed Mar 28 16:38:11 UTC 2012
Warren Young <warren at etr-usa.com>

On 3/26/2012 4:32 PM, John R Pierce wrote:
> On 03/26/12 2:20 PM, m.roth at 5-cent.us wrote:
>> Yeah... but parted is user hostile. A co-worker and I, both of whom don't
>> need GUIs, use gparted. However, that doesn't tell me where it's aligning
>> things.
> I don't think its any more user hostile than fdisk is, just perhaps less
> familiar.

parted(8) commits changes as you make them.  Those of us who grew up 
with :wq and File > Save (which seems to be fading away these days) 
expect to have the option of quitting without saving.  Automatic commit 
is fine if you expect it, so you plan your changes more carefully, but 
there's a whole lot of us with ingrained "never mind, get me out of 
here" Ctrl-C reflexes.

Worse, to my mind, is that parted(8) makes you explicitly give it more 
values than fdisk(8) does.  fdisk(8) uses information it has plus 
reasonable guesses to provide reasonable defaults for almost every 
question it asks:

- parted(8) can't create partitions on a new disk until you "mklabel".

You may claim the reason for this is that parted supports many partition 
table types, but actually, fdisk supports more than just MBR.  The 
essential difference is that fdisk(8) has a reasonable default, 
parted(8) does not.  Is there a good reason parted couldn't implicitly 
do "mklabel gpt" if you say "mkpart" on a zeroed disk?

- fdisk(8) gives reasonable defaults when creating partitions for the 
start and end values.  Its default start happens to be wrong in this 4K 
sector world, but parted(8) would be expected to fix that, if it offered 
a default.  Why should the operator be expected to know that starting at 
0 or 63 is a bad idea?  Why should the operator be expected to know that 
"-1" means "end of disk"?  Why should the operator have to do arithmetic 
to pack 8 partitions back-to-back?

You can trick parted(8) into doing some of the arithmetic for you; if 
you tell it all partitions start at 0, it offers to slide the new 
partition into position after existing ones.  But, this again gets into 
specialized knowledge the user really has no good reason to have.  fdisk 
doesn't make you think about partition start positions and it lets you 
give relative partition sizes instead of compute end values.

Maybe you don't see the problem.  Consider this partition layout:

/boot: 500 MB
swap: 16 GB
/: 20 GB
/home: the rest

In fdisk speak, the commands are:

n, p, 1, [Enter], +500m
n, p, 2, [Enter], +16g, t, 82
n, p, 3, [Enter], +20g
n, p, 4, [Enter], [Enter]

In parted speak, it is:

mklabel gpt
mkpart, [Enter], [Enter], 1m, 501m
mkpart, [Enter], linux-swap, 501m, 16.51g
mkpart, [Enter], [Enter], 16.51g, 36.51g
mkpart, [Enter], [Enter], 36.51g, -1

The fdisk sequence is more self-explanatory.  The only things it makes 
you tell it, which it should be able to guess or figure out on it own, 
are the partition numbers.

The fdisk sequence is also less arbitrary.  You might think the magic 
number 82 is more arbitrary than "linux-swap", but I tried "swap" first 
and got told to start over, proving it's just as arbitrary.

Oh, and realize that with parted(8) I had to manually ensure proper 
alignment the whole way.  If parted gave a default start value, it could 
ensure it was always aligned.

parted(8) has its points.  GPT support, partition types given by FS name 
instead of arbitrary MS-DOS type IDs, the ability to mkfs for *some* 
supported filesystem types (not all!), resizing...

Still, I'd have to agree with m.roth: parted(8) has a...um...classical 
UI.  It's not far advanced beyond the ex(1) school of UI design.