RFC: changing start sector in setup-storage

[Michael Tautschnig]

Hi all,

Let me first give a short summary of the context: Modern storage devices more
and more use 4k physical sector sizes instead of the original 512B sector sizes.
As such a change would result in a number of incompatibilities, the OS and
software continue to be presented with 512B sector sizes, and hardware takes
care of mapping read and write requests to the underlying physical sectors. What
looks like some minor implementation issue turns out to be causing performance
problems with the original DOS disk layout: in this setting, the first partition
starts at sector 63, meaning 63*512B. This results in misalignment with 4k
physical sector sizes, which degrades performance. Some more information about
this problem plus a number of pointers can be found in Mika's article [1].

To resolve this problem, Microsoft decided to start the first partition at
1M=2048*512B=256*4k. According to [2] Linux kernel folks consider it the best
approach to follow this decision. Assuming the list on that page is correct,
partitioning tools such as fdisk or parted will, by default, already follow this
proposal.

So how does this affect setup-storage, and why am I asking for additional input
concerning this problem?

setup-storage uses parted, but it forces partitions to start and end at certain
points instead of leaving parted to choose itself. Consequently we remain
independent of parted's changes regarding start sectors, but at the same time
also have to take this recent trend into account ourselves: Should setup-storage
follow the trend and make the first partition start at 1M or should we stick
with 63*512B? 

Should setup-storage be changed, this will affect anyone using preserve options.
It won't matter that much for fresh installs without preserved partitions, but
if some partition is preserved and all partitions listed before the preserved
partition have fixed sizes, setup-storage will fail miserably to determine a
viable disk layout. If anybody thinks they might be in such a situation, it
would be nice if they spoke up. 

Well, of course we can add yet another config option to specify the start sector
to be used. In fact the experimental builds already know an option "align-at"
that enforces proper alignment, e.g., for 4k sector sizes - but it won't give a
1M starting gap (unless you use align-at:1M, but that might have other
undesirable side effects).

In terms of code changes the move from 63*512B starting gap to 1M is almost
trivial, but I feel this might break a number of setups and hence would like to
give a chance to everyone to provide feedback before implementing this change.

Best regards,
Michael

[1] http://www.infoq.com/news/2010/03/4k-sectors
[2] https://ata.wiki.kernel.org/index.php/ATA_4_KiB_sector_issues

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.uni-koeln.de/pipermail/linux-fai/attachments/20101203/4c3b3667/attachment.bin>