Chris Murphy composed on 2015-03-15 10:03 (UTC-0600):
Felix Miata wrote:
I've yet to find a real world evaluation of the performance penalty imposed by not aligning to 4k.
Umm? There is no good reason to not align,
Maybe for you.
so why does this matter?
Because to me backwards compat across many multiboot installations is a plus. I see a size in partition size in inventory, and have a good idea what it means. Identical sizes are easily cloned as testing various hardware combinations dictates. Switching from legacy to aligned means two incompatible inventory sets.
And for two, there's piles of evaluation of this on linux-raid@ and it's all over the map because the penalty depends highly on workload, and the firmware revision. Some drives are just really slow with the internal read-modify-write, and others have optimized this so it's a minimal effect. The only way to evaluate this is to test it,
I'd like to see whatever data exists. Things get in the way of looking for it. Penalty for sustaining status quo isn't high.
but why bother? Just align properly. All the tools used these days do this correctly, parted, fdisk, gdisk, and so on.
I don't use "tools". I use one tool. If I want aligned, I get aligned, but it isn't forced upon me as if the only true way.
I usually have only one large blocksize partition use for truly large files, like CD & dvd isos. The backup system includes/assumes 255/63 too.
Are you referring to CHS addressing? This hasn't been used in Linux with any drive since probably 15 years or more.
It produced an understood alignment convention heavily implemented here long before HD makers decided to complicate life by changing physical sector sizes.
I don't want to conform to 4k before I know what the nuts & bolts cost of non-conformance is. Maybe I'd be happiest by ignoring alignment in test systems, conforming only in 24/7 systems, if even then.
You are needlessly making a big deal over a long ago solved problem.
On the contrary, the new solution created foreseeable and unforeseeable fallout, as so often happens as development evolves and developers decide backwards compat is too much trouble to keep.
It occasionally remains an issue with dual boot installs with Windows XP and newish drives, because XP's partitioner starts the first partition at LBA 63, which is not aligned.
It's aligned, just not to a 4k multiple. It's aligned to a multiple of 255*63 or 240*63, de facto standards before the HD makers decided everyone needed only huge storage devices, for which 512 byte physical sectors had to dodo.
It sometimes comes up with older enterprise linux that for some reason dragged their feet applying patches to start the 1st sector at LBA 2048. But I'd be surprised if you're using any version of openSUSE released in the past ~8 years that does this incorrectly.
As I don't use but one partitioner, all partitioning is necessarily done before any OS installers are run. How they do what they do is irrelevant here.
But all you have to do is look at the start LBA for each partition. Is it divisible by 8 (or 2048 if you want 1MiB alignment - it's easier)? If yes, you're done. If no, start over.
Starting over costs. I avoid fixing what ain't broke, leaving more time to find what does need fixing. FWIW, thread's HD is out, replacement in. Problems that are obviously a result of HD bad are gone, but the inexplicable long delays at kernel/initrd load time remain for TW, 13.2, Cauldron and Rawhide. 11.4, 12.1, 12.2, 12.3, 13.1, F21 & F22 load right up normally. Getting this far has been an extra pain due to the initrd married to root's UUID problem we've reported.[1] I hadn't remembered to undo hostonly on the Mageias as I had on the Fedoras, and didn't need to think about for TW or 13.2. https://bugzilla.redhat.com/show_bug.cgi?id=1187007 https://bugs.mageia.org/show_bug.cgi?id=15500 -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org