GPT vs MBR for swap devices
imp at bsdimp.com
Wed Jun 13 16:09:22 UTC 2018
On Wed, Jun 13, 2018 at 9:48 AM, bob prohaska <fbsd at www.zefox.net> wrote:
> In trying to get a Pi3 at r334939 to run -j4 buildworld it's become clear
> that a USB flash (Sandisk Extreme) swap device very quickly triggers OOM
> process kills, while a USB mechanical disk swap devices works perfectly.
> It's somewhat hard to believe that the Sandisk Extreme is much slower than
> a mechanical hard drive for small reads and writes if the rated speeds are
> anywhere close to correct, but it happens that the flash device uses MBR
> partitioning, while the mechanical hard drive uses GPT.
> Is there any reason to think that the partitioning scheme matters?
Usually, partitioning doesn't matter.
USB flash drives are optimized for (a) being big and (b) writing large
Neither of these is good for swap space. So, lots of 'small' writes that
the swapper does can often trigger pathological behavior in the drive's FTL
(that's a polite way to say performance goes through the floor). I've seen
on SSDs, which have better FTLs, that can easily do 500MB/s drop to
10-20MB/s when reads and writes are mixed with the wrong workload. Our
swapper is written with the assumption that all writes are equal and small
ones are better than larger ones (since they free up the dirty pages
faster). However, you can often get better performance out of larger writes
and I don't think there's a knob to twist for that.
I should have added (c) and sometimes for FAT file systems. That used to be
the case. And for that MBR used to be a little better. However, that was 5
years ago or so. With the new Sandisk Extreme drives it isn't so much since
they are so large and FAT isn't good enough for most people these days. My
experience with them recently has been they are OK drives. The write speed
is kinda crappy (maybe 50-60MB/s when streaming a file to them, and
20-3MB/s in a mixed workload), but their read speed is surprisingly good at
up to about 200MB/s when there's no flash contention. My main concern,
though, was copying a 16GB video to them and making sure it would play back
OK. For that they are good. For backing up the video project with all it's
little files, not so good, and doing 'du' on it while copying slowed the
copying down a lot, even though it wasn't that much traffic to the drive.
All of this was on macOS, though.
More information about the freebsd-arm