RFC: changing start sector in setup-storage

[Michael Prokop]

* Brian Kroth <bpkroth at gmail.com> [Mon Dec 20, 2010 at 12:03:44PM -0600]:
> Michael Tautschnig <mt at debian.org> 2010-12-03 21:31:

> > 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.
[...]

> > 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? 

[...]

> > [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?

Well, you can configure size of /boot anyway, so this shouldn't be
an issue. Regarding preservation of LVM there are some recent
threads on the mailinglist and in Debian's BTS IIRC.

Actually, on all non-embedded and non-virtualized systems I'm using
something like 2GB for /boot (iff /boot is a separate partition), to
have enough space for different kernel versions as well as ISO boot
(loopback and memdisk, depending on what I need). This provides the
option to have rescue systems as well as firmware/BIOS updates
integrated directly within the bootloader. Very comfortable from the
sysadmin POV. :)

So worrying about possibly losing up to 1MB is definitely out of
scope for setup-storage, IMHO.

> 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.

A sane default would be good for performance reasons. Having the
option to override the alignment if necessary would be nice to force
a specific setup that's not matched by the default.

Regarding the sane default, I'd go the parted way-of-life (1MB,
4k,..) and if there any open questions we could get in touch with
the parted developers and ask for their input.

Kind of related BTW, see thread "RFC: future size of embed area in
partition labels" on debian.ports/debian.devel.boot, e.g.
http://permalink.gmane.org/gmane.linux.debian.ports.bsd/5522

regards,
-mika-
-- 
http://michael-prokop.at/  || http://adminzen.org/
http://grml-solutions.com/ || http://grml.org/
-------------- 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/20101221/86a3ef56/attachment.bin>