[CentOS] One disk speed problem [SOLVED], and a question on hdparm
warren at etr-usa.com
Wed Mar 28 16:38:11 UTC 2012
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
> I don't think its any more user hostile than fdisk is, just perhaps less
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:
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.
More information about the CentOS