I believe I've posted before about one of the speed issues we were having, of backups taking many, many hours that should *not* take that long.
My manager and I finally nailed it down to the h/d itself. Identical boxes, and he tried a backup of one system which took under two hours, while the same regular one rand nearly six.
I'd been googling on and off for weeks, and this morning, ran across something: partition alignment. A thread where someone who'd done some tests and found that was his problem.
So, here's the answer: we have these Caviar Green 2tb drives (the thread I found had either a 1tb, or 1.5tb), (and no, we are *NOT* going to buy Caviar Green for servers ever again). The big thing is that they use 4k sectors, *not* 512 bytes. Following directions, I pulled it into fdisk, and then used a command I've not needed before: u. This changes units from cylinders (the default) to sectors. Having done that, p shows that it actually starts in sector 63. Again, following directions, I changed it to start in sector 64. Finished the partition, wrote it, made the filesystem, and tried it out.
177G transferred in 1h 47+m.
So, anyone who's got new drives that use 4k sectors should probably follow this.
This also probably explains parted's completely aggravating complaint that the partition's not aligned, but gives you no idea *why*, or how to align it - I pulled the drive into parted, and told it to print, and it did *not* complain the partition wasn't aligned.
Next trick: hdparm. I want to disable, or at least shove way up, the spindown timeout on these drives, which, depending on the thread you read, is 6 or 8 seconds. hdparm should let me do that... but before I do, I'd like to know what it's set at. Does anyone know how to find that out? And no, the manpage is wrong, hdparm -B <no parm) /dev/sdx does *not* read it, it just complains it's missing the parm.
mark
On 03/26/12 1:49 PM, m.roth@5-cent.us wrote:
So, here's the answer: we have these Caviar Green 2tb drives (the thread I found had either a 1tb, or 1.5tb), (and no, we are*NOT* going to buy Caviar Green for servers ever again). The big thing is that they use 4k sectors,*not* 512 bytes. Following directions, I pulled it into fdisk, and then used a command I've not needed before: u. This changes units from cylinders (the default) to sectors. Having done that, p shows that it actually starts in sector 63. Again, following directions, I changed it to start in sector 64. Finished the partition, wrote it, made the filesystem, and tried it out.
almost all newer large capacity drives are using 4k sectors internally now. SSD physical block sizes are something like 128k bytes, so the problem is even worse.
I'd suggest getting in the habit of using parted rather than fdisk, as fdisk can't handle GPT formatted disks, and MBR can't handle anything over 2TB
John R Pierce wrote:
On 03/26/12 1:49 PM, m.roth@5-cent.us wrote:
So, here's the answer: we have these Caviar Green 2tb drives (the thread I found had either a 1tb, or 1.5tb), (and no, we are*NOT* going to buy Caviar Green for servers ever again). The big thing is that they use 4k sectors,*not* 512 bytes. Following directions, I pulled it into fdisk, and then used a command I've not needed before: u. This changes units from cylinders (the default) to sectors. Having done that, p shows that it actually starts in sector 63. Again, following directions, I changed it to start in sector 64. Finished the partition, wrote it, made the filesystem, and tried it out.
almost all newer large capacity drives are using 4k sectors internally now. SSD physical block sizes are something like 128k bytes, so the problem is even worse.
I'd suggest getting in the habit of using parted rather than fdisk, as fdisk can't handle GPT formatted disks, and MBR can't handle anything over 2TB
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.
This info - oh, meant to give the link to the author of the informative thread: http://linuxconfig.org/linux-wd-ears-advanced-format - does tell you what and why. Next time I need to build a 3TB drive (which will be soon), I'll play with parted, and see if it complains if I align it this way.
mark mark
On 03/26/12 2:20 PM, m.roth@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.
On 3/26/2012 4:32 PM, John R Pierce wrote:
On 03/26/12 2:20 PM, m.roth@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.
Warren Young wrote:
On 3/26/2012 4:32 PM, John R Pierce wrote:
On 03/26/12 2:20 PM, m.roth@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.
<snip>
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.
I disagree. I don't think it's advanced beyond that school....
mark
On Wed, Mar 28, 2012 at 12:02 PM, m.roth@5-cent.us wrote:
<snip> 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.
I disagree. I don't think it's advanced beyond that school....
Yes, it is so bad that it is surprising that there is not a text-mode program that performs the functions of gparted - or is there one? That is, something that gives you a fill-in-the-form setup with reasonable defaults, then runs parted (and maybe mklabel, mkfs, etc.) for you. Do we really need to run X for that?
On Wed, 2012-03-28 at 12:32 -0500, Les Mikesell wrote:
On Wed, Mar 28, 2012 at 12:02 PM, m.roth@5-cent.us wrote:
<snip> 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.
I disagree. I don't think it's advanced beyond that school....
Yes, it is so bad that it is surprising that there is not a text-mode program that performs the functions of gparted - or is there one? That is, something that gives you a fill-in-the-form setup with reasonable defaults, then runs parted (and maybe mklabel, mkfs, etc.) for you. Do we really need to run X for that?
Hi
I have been using gdisk for at least a year on Centos and F15/F16
Current Centos 6.2 server disk was probably partitioned using F15 gdisk followed by a custom install of C6.0
Centos 6.2 gdisk is now installed on the server (maui, 256GB SSD)
[root@maui ~]# gdisk /dev/sda GPT fdisk (gdisk) version 0.8.1
Partition table scan: MBR: protective BSD: not present APM: not present GPT: present
Found valid GPT with protective MBR; using GPT.
Command (? for help): p Disk /dev/sda: 468862128 sectors, 223.6 GiB Logical sector size: 512 bytes Disk identifier (GUID): 238914FA-2437-4AD8-B803-5CA2860D9D93 Partition table holds up to 128 entries First usable sector is 34, last usable sector is 468862094 Partitions will be aligned on 2048-sector boundaries Total free space is 2014 sectors (1007.0 KiB)
Number Start (sector) End (sector) Size Code Name 1 2048 4095 1024.0 KiB EF02 BIOS boot partition 2 4096 2101247 1024.0 MiB EF00 Linux/Windows data 3 2101248 6295551 2.0 GiB 8200 Linux swap 4 6295552 69210111 30.0 GiB 0700 Linux/Windows data 5 69210112 132124671 30.0 GiB 0700 Linux/Windows data 6 132124672 174067711 20.0 GiB 0700 Linux/Windows data 7 174067712 468862094 140.6 GiB 0700 Linux/Windows data
Command (? for help): q [root@maui ~]# uname -a Linux maui.jaa.org.uk 2.6.32-220.7.1.el6.x86_64 #1 SMP Wed Mar 7 00:52:02 GMT 2012 x86_64 x86_64 x86_64 GNU/Linux
John
On Wed, Mar 28, 2012 at 1:10 PM, John Austin ja@jaa.org.uk wrote:
I have been using gdisk for at least a year on Centos and F15/F16
But that doesn't seem happy with MBR type disks. You don't need GPT unless the disk is bigger then 2 Gigs and 4k-sector drives start at 750G, at least in the laptop sizes. gdisk -l says this about a layout created by the Centos installer:
Partition table scan: MBR: MBR only BSD: not present APM: not present GPT: not present
*************************************************************** Found invalid GPT and valid MBR; converting MBR to GPT format. ***************************************************************
Warning! Secondary partition table overlaps the last partition by 33 blocks! You will need to delete this partition or resize it in another utility. Disk /dev/sda: 262144000 sectors, 125.0 GiB Logical sector size: 512 bytes Disk identifier (GUID): 4E46CCD4-4010-401E-84A8-020B674DA64B Partition table holds up to 128 entries First usable sector is 34, last usable sector is 262143966 Partitions will be aligned on 2048-sector boundaries Total free space is 2014 sectors (1007.0 KiB)
Number Start (sector) End (sector) Size Code Name 1 2048 1026047 500.0 MiB 8300 Linux filesystem 2 1026048 262143999 124.5 GiB 8E00 Linux LVM
Is something really wrong with it?
On 3/28/2012 11:32 AM, Les Mikesell wrote:
Yes, it is so bad that it is surprising that there is not a text-mode program that performs the functions of gparted - or is there one?
There's cgdisk, from the gdisk package in EPEL.
It solves most of the problems called out in my rant.
On 3/28/2012 11:02 AM, m.roth@5-cent.us wrote:
Warren Young wrote:
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.
I disagree. I don't think it's advanced beyond that school....
Now, be fair. ex(1) responded to all errors with:
?
Ya gotta give it to parted(8), it ain't that bad.
Warren Young wrote:
On 3/28/2012 11:02 AM, m.roth@5-cent.us wrote:
Warren Young wrote:
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.
I disagree. I don't think it's advanced beyond that school....
Now, be fair. ex(1) responded to all errors with:
?
Ya gotta give it to parted(8), it ain't that bad.
But... but... parted responds to all partitioning with a statement that the partition's not aligned. And that's, well, memory's much cheaper these days, they can afford 80 chars instead of one.
mark
On Mon, Mar 26, 2012 at 4:20 PM, m.roth@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 think its trick is the default 1M offset it adds at the start.
Les Mikesell wrote:
On Mon, Mar 26, 2012 at 4:20 PM, m.roth@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 think its trick is the default 1M offset it adds at the start.
You may be right... but I'm not sure. We'll see if the 3tb drive I've just formatted takes less time - the others I used gparted with.
mark
On 03/28/2012 08:00 AM, m.roth@5-cent.us wrote:
Les Mikesell wrote:
On Mon, Mar 26, 2012 at 4:20 PM, m.roth@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 think its trick is the default 1M offset it adds at the start.
You may be right... but I'm not sure. We'll see if the 3tb drive I've just formatted takes less time - the others I used gparted with.
mark
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
I've found every one of these utilities to be problematic at various time, particularly on systems with a GPT bios. Each one seems to have its own strengths and weaknesses. Though I don't remember exactly how it works, my recollection is that there are ways to trick fdisk into doing alignment by specifying the -H (number of heads) and the -S (number of sectors per track). You'll have 1 unaligned partition at the beginning because of the MBR, but all the rest can be forced into the desired alignment.
Nataraj
on 3/26/2012 1:49 PM m.roth@5-cent.us spake the following:
I believe I've posted before about one of the speed issues we were having, of backups taking many, many hours that should *not* take that long.
My manager and I finally nailed it down to the h/d itself. Identical boxes, and he tried a backup of one system which took under two hours, while the same regular one rand nearly six.
I'd been googling on and off for weeks, and this morning, ran across something: partition alignment. A thread where someone who'd done some tests and found that was his problem.
So, here's the answer: we have these Caviar Green 2tb drives (the thread I found had either a 1tb, or 1.5tb), (and no, we are *NOT* going to buy Caviar Green for servers ever again). The big thing is that they use 4k sectors, *not* 512 bytes. Following directions, I pulled it into fdisk, and then used a command I've not needed before: u. This changes units from cylinders (the default) to sectors. Having done that, p shows that it actually starts in sector 63. Again, following directions, I changed it to start in sector 64. Finished the partition, wrote it, made the filesystem, and tried it out.
177G transferred in 1h 47+m.
So, anyone who's got new drives that use 4k sectors should probably follow this.
This also probably explains parted's completely aggravating complaint that the partition's not aligned, but gives you no idea *why*, or how to align it - I pulled the drive into parted, and told it to print, and it did *not* complain the partition wasn't aligned.
Next trick: hdparm. I want to disable, or at least shove way up, the spindown timeout on these drives, which, depending on the thread you read, is 6 or 8 seconds. hdparm should let me do that... but before I do, I'd like to know what it's set at. Does anyone know how to find that out? And no, the manpage is wrong, hdparm -B<no parm) /dev/sdx does *not* read it, it just complains it's missing the parm.
mark
Isn't it sdparm for scsi and scsi emulations?
Scott Silva wrote:
on 3/26/2012 1:49 PM m.roth@5-cent.us spake the following:
<snip>
Next trick: hdparm. I want to disable, or at least shove way up, the spindown timeout on these drives, which, depending on the thread you read, is 6 or 8 seconds. hdparm should let me do that... but before I
do, I'd
like to know what it's set at. Does anyone know how to find that out? And no, the manpage is wrong, hdparm -B<no parm) /dev/sdx does *not* read it, it just complains it's missing the parm.
Isn't it sdparm for scsi and scsi emulations?
That may be around, but they've updated hdparm to deal with SATA as well.
mark
-
John Austin -
John R Pierce -
Les Mikesell -
m.roth＠5-cent.us -
Nataraj -
Scott Silva -
Warren Young