Hi Christian, if you were to have a 1MB file or a database that needed to read 1MB of data, i f the partitions are not aligned then your underlying storage system need to load 2 chunks or write 2 chunks for 1 MB of data, written,
So *worst* case you would double the workload for the storage hardware (SSD or Hardware RAID with large chunks) for each transaction on writing to SSDs if you are not aligned one could *worst *case double the write / wear rate. The improvement would be less for accessing small files and writing small files (as they would need to be across 2 Chunks ) The following paper explains (better than I do ) https://www.vmware.com/pdf/esx3_partition_align.pdf if the cost is 1-8MB at the start of the disk (assuming partitions are sized so that they dont loose the ofset of 2048 sectors) I think it is worth pursuing. (again I only have experience on amd64 /i386 hardware) Thanks Tom Smyth On Tue, 20 Apr 2021 at 22:52, Christian Weisgerber <na...@mips.inka.de> wrote: > > Tom Smyth: > > > just installing todays snapshot and the default offset on amd64 is 64, > > (as it has been for as long as I can remember) > > It was changed from 63 in 2010. > > > Is it worth while updating the defaults so that OpenBSD partition > > layout will be optimal for SSD or other Virtualized RAID environments > > with 1MB Chunks, > > What are you trying to optimize with this? FFS2 file systems reserve > 64 kB at the start of a partition, and after that it's filesystem > blocks, which are 16/32/64 kB, depending on the size of the filesystem. > I can barely see an argument for aligning large partitions at 128 > sectors, but what purpose would larger multiples serve? > > > Is there a down side to moving the default offset to 2048 ? > > Not really. It wastes a bit of space, but that is rather insignificant > for today's disk sizes. > > -- > Christian "naddy" Weisgerber na...@mips.inka.de > -- Kindest regards, Tom Smyth.
