I currently have a 1 TiB NVMe drive that has been hovering at 100 GiB left for the past couple months. I’ve kept it down by deleting a game every couple weeks, but I would like to play something sometime, and I’m running out of games to delete if I need more space.
That’s why I’ve been thinking about upgrading to a 2 TiB drive, but I just saw an interesting forum thread about LVM cache. The promise of having the storage capacity of an HDD with (usually) the speed of an SSD seems very appealing, but is it actually as good as it seems to be?
And if it is possible, which software should be used? LVM cache seems like a decent option, but I’ve seen people say it’s slow. bcache is also sometimes mentioned, but apparently that one can be unreliable at times.
Beyond that, what method should be used? The Arch Wiki page for bcache mentions several options. Some only seem to cache writes, while some aim to keep the HDD idle as long as possible.
Also, does anyone run a setup like this themselves?
L2ARC is not a read cache in the conventional sense, but something closer to swap for disks only. It is only effective if your ARC hit rate is really low from memory constraints, although I’m not sure how things stack up now with persistent L2ARC. ZFS does have special allocation devices, though, where metadata and optionally small blocks of data (which HDDs struggle with) can go, but you can lose data if these devices fail. There’s also the SLOG, where sync writes can go. It’s often useful to use something like optane drives for it.
Personally, I’d just keep separate drives. A lot of caching methods are afterthoughts (bcache is not really maintained as Kent is now working on bcachefs) or, like ZFS, are really complex are not true readback/writeback caches. In particular, LVM cache can, depending on its configuration, lead to data loss if a cache device is lost, and LVM itself can occur some overhead.
Flash is cheap. A 2TB NVMe drive is now roughly the cost of 2 AAA games (which is sad, really). OP should just buy a new drive.