Hello Otto, Christian,
I was relying on that paper for the pictures of the alignment issue,
VMFS (vmware file system) since version 5 of vmwarehas allocation
units of 1MB each
https://kb.vmware.com/s/article/2137120
my understanding is that SSDs have a similar allocation unit setup of 1MB,
and that aligning your file system to 1MB would improve performance
|OpenBSD Filesystem --------------| FFS-Filesystem
|VMDK Virtual Disk file for Guest | OpenBSD-Gusest-Disk0.vmdk
|vmware datastore------ ------------| 1MB allocation
|Logical Storage Device / RAID---|
|SSD or DISK storage --------------| 1MB allocation unit (on some SSDs)
Figure 2 of the following paper shows what
https://www.usenix.org/legacy/event/usenix09/tech/full_papers/rajimwale/rajimwale.pdf
as your writes start to cross another underlying block boundary you
see a degradation of performance
largest impact is on a write o1 1MB (misaligned) across 2 blocks,
but it repeats as you increase the number of MB in a transaction but
the % overhead
reduces for each additional 1MB in the Transaction.
If there is no downside to allocating /Offsetting filesystems on 1MB
boundaries,
can we do that by default to reduce wear on SSDs, and improve performance
in Virtualized Environments with large allocation units on what ever storage
subsystem they are running.
Thanks for your time
Tom Smyth
Post by Otto MoerbeekPost by Tom SmythHi 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)
Doing a quick scan trhough the pdf I only see talk about 64k boundaries.
FFS(2) will split up any partiition in multiple cylinder groups. Each
cylinder group starts with a superblock copy, inode tables and other
meta datas before the data blocks of that cylinder group. Having the
start of a partion a 1 1MB boundary does not get you those data blocks
at a specific boundary. So I think your resoning does not apply to FFS(2).
It might make sense to move the start to offset 128 for big
partitions, so you align with the 64k boundary mentioned in the pdf,
the block size is already 64k (for big parttiions).
-Otto
Post by Tom SmythThanks
Tom Smyth
Post by Christian WeisgerberPost by Tom Smythjust 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.
Post by Tom SmythIs 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?
Post by Tom SmythIs 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.
--
--
Kindest regards,
Tom Smyth.
--
Kindest regards,
Tom Smyth.