RFC: changing start sector in setup-storage

[Brian Kroth]

Michael Tautschnig <mt at debian.org> 2010-12-03 21:31:
> 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

Sorry for the slow response and if this is too specific to offer any
guidance.

I tend to use a layout basically makes a small (128-256M) /boot
partition, then carves the rest up for LVM to play with.  On that LVM I
usually specify a single partition (eg: /home) that I want to be
preserved, but I'll let the rest of it get blown away.  With that in
mind, do you think setup-storage tweaks could be made to allow /boot to
perhaps become a little smaller, but then leave enough of the other
partition alone to allow for preserving my /home lv?

More generally, I tend to think giving people the option is best.  I
like the notion of an align-at argument that defaults to the new value
(4K?), and then send out a big red warning in the changes/release
announcement that says something along the lines of "if you want the old
behavior/preserving to work, set align-at=512B".

Then again, in my own experience preserve has always been a little
finicky anyways.  By the time I get around to wanting to completely
reinstall a machine, I probably want to change the layout anyways.

Thanks,
Brian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://lists.uni-koeln.de/pipermail/linux-fai/attachments/20101220/88e2ab5c/attachment.bin>