Michael Tautschnig <[email protected]> 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
signature.asc
Description: Digital signature
