Thanks Stuart, you went further than I Did :)
On Wed, Feb 15, 2017 at 11:39 PM, Stuart Henderson <s...@spacehopper.org> wrote:
> On 2017/02/15 23:22, Tom Smyth wrote:
>> Hello,
>>
>> I have been installing OpenBSD quite a bit in a virtualization
>> environment and the
>> underlying storage has been formatted in 1MB blocks, and most other
>> operating
>> systems have recommended for best performance to align the partition on a 1MB
>> Offset rather than a smaller value.
>>
>> the reasoning behind this is that if you have files that are around
>> than 1MB in size
>> and they are stored in the file system it is likely that they will
>> cross a block boundary and while OpenBSD only wants to read the file,
>> the underlying storage system
>> will have to retrieve 2 blocks and this is wasteful on resources.
>>
>> If the offset was set to 2048 sectors (at 1MB in my case) the disk
>> performance of OpenBSD on my underlying system would be improved.
>> I have been setting the value of the initial offset to 2048 and I have
>> used exact sizes in-terms of sector count to keep my subsequent
>> partitions aligned with the 1M offset,
>> I have not noticed any ill affect on my installs (for the past 2
>> years) and I think it
>> would be worth considering this as a suggested default when installing
>> OpenBSD
>>
>> Any comments suggestions insights welcome, as my experience on
>> virtualization
>> has been Vmware Based. But I would imagine most modern enterprise
>> storage systems are using larger block sizes... and by setting it to a
>> 1MB or perhaps a larger value (as long as the value ends on a 1MB
>> Boundary eg 2MB or 4MB) depending on other users experience
>>
>
> I've been doing similar for installs on SSDs with their large erase blocks.
> And this is common on other OS these days.
>
> As you say, it's not just the starting point of the OpenBSD part of the disk,
> care must be taken with the disklabel partitions too.
>
> I have an old tree that has this diff in, I don't remember if it was quite
> enough for disklabel as-is, but it might be enough of a starting point to
> save time tracking things down.
>
> Index: fdisk/mbr.c
> ===================================================================
> RCS file: /cvs/src/sbin/fdisk/mbr.c,v
> retrieving revision 1.67
> diff -u -p -r1.67 mbr.c
> --- fdisk/mbr.c 1 Sep 2016 16:17:46 -0000 1.67
> +++ fdisk/mbr.c 15 Feb 2017 23:36:29 -0000
> @@ -144,8 +144,11 @@ MBR_init(struct mbr *mbr)
> }
> #endif
>
> - /* Start OpenBSD MBR partition on a power of 2 block number. */
> - i = 1;
> + /*
> + * Start OpenBSD MBR partition on a power of 2 block number
> + * with a minimum 2048-block alignment.
> + */
> + i = 2048;
> while (i < DL_SECTOBLK(&dl, mbr->part[3].bs))
> i *= 2;
> adj = DL_BLKTOSEC(&dl, i) - mbr->part[3].bs;
> Index: disklabel/editor.c
> ===================================================================
> RCS file: /cvs/src/sbin/disklabel/editor.c,v
> retrieving revision 1.304
> diff -u -p -r1.304 editor.c
> --- disklabel/editor.c 6 Oct 2016 13:02:31 -0000 1.304
> +++ disklabel/editor.c 15 Feb 2017 23:36:29 -0000
> @@ -2092,8 +2092,7 @@ align:
> orig_size = DL_GETPSIZE(pp);
> orig_offset = DL_GETPOFFSET(pp);
>
> - bsize = (DISKLABELV1_FFS_FRAG(pp->p_fragblock) *
> - DISKLABELV1_FFS_FSIZE(pp->p_fragblock)) / lp->d_secsize;
> + bsize = 2048;
> if (DL_GETPOFFSET(pp) != starting_sector) {
> /* Can't change offset of first partition. */
> adj = bsize - (DL_GETPOFFSET(pp) % bsize);
>
