Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I'm trying to figure out if there's some way I can tell if a system is being adversely affected by disk misalignment -- i.e. when I do a disk I/O operation, it actually needs to request extra blocks from the back end storage (we're using a SAN) because the requested block of data actually lives on multiple blocks on the actual disk.

This problem allegedly affects VMs even more, as the disks are abstracted so that blocks don't align because of improper sector offsets, causing additional IOPS to be used when accessing the backend storage from the VM.

Anyway, I've been looking at iostat output, and it seems like there's data there that might give me a clue to this, but I seem to be slow at reasoning through it. Is there some clue to indicate with iostat (or something else) that the machine might be performing more disk I/Os that optimal?

(I'm not convinced that disk alignment is worth the effort to investigate/worry about, but I would love some opinions on the matter!)

share|improve this question
add comment

1 Answer

up vote 3 down vote accepted

Disk alignment used to be rather trivial to figure out. All the tracks had the same number of sectors of the same size. Modern high density drives use variable numbers of sectors per track maintaining roughly the same bit density on the platter. They still report the old sizing information of cylinders, tracks, and sectors. Actual sector geometry varies depending on where on the disk it is being written.

Actual addressing is usually done in LBA (Logical Block Addressing) format. And really doesn't care about the disk geometry. Split I/Os are likely to be done by the disks control software. You may get split I/Os where you don't expect them, and not where you expect them.

Put those disks in a SAN and share them out, and the geometry gets hidden behind another layer of geometry. At that point I wouldn't even try to hazard a guess at which I/Os were split when. I would be more interested in the SANs view which will likely stripe the data in some size which is a power of 2, likely somewhere between 4Kb and 4Mb. I/O on these boundaries will be split across disks. You SAN administrator should be able to tell you the SAN allocation size. It the allocation size is small it might be an advantage to align your partitions and block sizes with that of the SAN.

I generally look at sar output to see if Disk I/O is getting to be a problem. You will see average queue size and service times increasing when you have an I/O problem. At that point you need to start looking at why I/O is a problem. With a SAN it could occur at a number of places. There are a variety of solutions. For virtual machines, I would lean to separate SAN disks for each machine. These can be allocated as raw disks to the virtual machines rather than one of the virtual disk in a file formats like VMDK.

share|improve this answer
    
ah, excellent, sar -d seems to give some good stats that I can use for comparison. thanks! –  dmkmills Feb 8 '11 at 19:50
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.