5 ms·

Fast and cheap bulk storage: using LVM to cache HDDs on SSDs

223 points by todsacerdoti 1y ago

hinkley 1y ago
Seems like there’s a very old trick we may have forgotten: put your WAL file on the fastest storage you have to speed up your database. I’d like to see benchmarks comparing both on the same hardware.
gopalv 1y ago
As always the YMMV of caching is access patterns, but the more consistent cacheable pattern has been the ext4 journals for me. They are tiny and often hit with a huge number of IOPS. Ext4 supported external journals and moving it to a single SSD for a large number of otherwise slow SMR disks has worked great in the past. However, when you hit a failure that SSD becomes a single root cause of data loss from several disks when losing that SSD (unlike a read cache). Where I was working that didn't matter as I was mostly working with HDFS which both likes a JBOD layout of several disks instead of RAID (no battery backed write caches), tolerant to a single node failing completely and having a ton more metadata operations thanks to writing a single large file as many fixed-size files named blk_<something> with a lot of directories containing thousands of files. SSDs were expensive then, but it's been a decade of getting cheaper from that.
- trinsic2 1y ago
  This reminds me of the hybrid drives. When the NVM failed its was a nightmare to deal with. IMHO it's a bad idea from a stability perspective to be caching off drive to Non-volatile memory.
  - wtallis 1y ago
    Your last sentence does not follow from the preceding one. Hybrid drives were doomed by having truly tiny caches, making them not particularly fast (you need a lot of flash chips in parallel to get high throughput), prone to cache thrashing, and easy to wear out the NAND flash. These days, even if you try, it's hard to build a caching system that bad. There just aren't SSDs small and slow enough to have such a crippling effect. Even using a single consumer SSD as a cache for a full shelf of hard drives wouldn't be as woefully unbalanced as the SSHDs that tried to get by with only 8GB of NAND.
- GauntletWizard 1y ago
  The same for ZFS; there's provisioning to make a "zil" device - ZFS Intent Log, basically the journal. ZFS is a little nicer in that this journal is explicitly disposable - If you lose your ZIL device, you lose any writes since it's horizon, but you don't lose the whole array. The next step up is building a "metadata" device, which stores the filesystem metadata but not data. This is dangerous in the way the ext4 journal is; lose the metadata, and you lose everything. Both are massive speedups. When doing big writes, a bunch of spinning rust can't achieve full throughput without a SSD ZIL. My 8+2 array can write nearly two gigabits, but it's abysmal (roughly the speed of a single drive) without a ZIL. Likewise, a metadata device can make the whole filesystem feel as snappy as SSD, but it's unnecessary if you have enough cache space; ZFS prefers it, so if your metadata fits into your cache SSD, most of it will stay loaded
  - Szpadel 1y ago
    I just want to mention that ZIL is just to speed up sync writes, as it ends syscall when data are written to ZIL, but might be still in progress on slower storage. ZIL is also basically write only storage, therefore sad without very significant over provisioning will die quickly (you only read from ZIL after unclean shutdown) if you don't really case about latest version of file (risk of loosing recent chances is acceptable) you might set sync=disabled for that dataset and you can have great performance without ZIL
    - magicalhippo 1y ago
      Minor nitpick, your post is primarily talking about SLOG, separate intent log. The pool always has a ZIL, but you can put it on a separate device, or decices, with SLOG[1]. [1]: https://www.truenas.com/docs/references/zilandslog/ https://www.truenas.com/docs/references/zilandslog/
  - JonChesterfield 1y ago
    There's a configuration option that amounts to putting a directory (or maybe a volume) entirely into the metadata drive. It's been a long time since I set that up, but the home storage has spinning rust plus a raid 1 of crucial ssd (sata! But ones with a capacitor to hopefully handle writes after power loss), where the directory I care about performance for lives on the ssd subarray. Still presents as one blob of storage. Metadata on the ssd too, probably no ZIL but could be wrong about that. Made ls a lot more reasonable. Thinking about it that system must be trundling towards expected death, it might be a decade old now.
- Dylan16807 1y ago
  > However, when you hit a failure that SSD becomes a single root cause of data loss from several disks when losing that SSD (unlike a read cache). In theory you can massively reduce this risk by keeping a copy of the journal in memory so it only corrupts if you have a disk loss and a power outage within a few seconds of each other. But I don't know if the tools available would let you do that properly.
- hinkley 1y ago
  Twin SSDs and RAID 1.
bjt12345 1y ago
Oh I miss Optane drives.
- dur-randir 1y ago
  Grab one from Aliexpress while you stil can)
ggm 1y ago
The logic for not zfs cited reduces to two things: FUD and not in baseline Linux. The pro case for BTRFS is being able to do JBOD with a bit of additional comfort around mirror state over drives.
- dangus 1y ago
  Yeah I really didn’t understand why ZFS or something like a TrueNAS dedicated storage solution setup was ruled out so quickly. But before we even go there, we have to consider an all-SSD solution. SSDs are so cheap nowadays. It’s a trivial cost to buy a 2-4TB SSD. Heck, even an 8TB SSD is reasonably affordable, only about $600. So first step is justifying a complicated caching setup. Why cache at all when you can just use all SSD storage and bring the complexity down a whole lot? And if you’re using more than 2-8TB of storage and you’re in the spinning disk territory, why are you not using a dedicated NAS solution like TrueNAS? This solution just seems like one of the worst possible choices.
  - dur-randir 1y ago
    I have a 100TB array setup with LVM. I've thought (twice, each time I expanded this array) about using ZFS. It was ruled out for three things: - there had been no raidz expansion (but now is, so this point is crossed) - ZFS degrades read latency with the number of drives in array, while mdraid/lvm scales linearly - this is the price you pay for your checksums - write-cache options on ZFS are atrotious, ZIL/SLOG are nothing compared to dm_writecache - I can stream 2GB/s full of sync writes until my cache drive is filled up, and it also provides reads to freshly written data, without going to backing pool So, saying "why not ZFS" or "go buy some SSDs" is not really productive for promoting ZFS - it just underscores that "for ZFS" crowd are zealots.
    - ggm 1y ago
      Maybe I skimmed too fast, but I didn't see your criticisms in the write up cited. They're a good critique, ssd aside: ssd are magic, any filesystem. ZFS mainline kernel aside, is the only FS I've seen which is able to encompass redundancy and is portable BSD <-> Linux. It isn't a big reason I run it, but it's one of them. Snapshotting is the big reason although the various journal fs had this ages ago. I don't personally feel a zealot, but I admit to proselytising.
Szpadel 1y ago
something that people forget with raid1 is that this only protect from catastrophic disk failure. this means your your drive need to be dead for raid to do it's protection and this is usually the case. the problem is when starts corrupting data it reads of writes. in that case raid have no way to know that and can even corrupt data on the healthy drive. (data is read corrupted and then written to both drives) the issue is that there are 2 copies of the data and raid have no way of telling with one is correct so it's basically flips a coin and select one of them, even if filesystem knows that content makes no sense. that's basically biggest advantage of filesystems like zfs or btrfs that manage raid themselves, they have checksums and that know with copy is valid and are able to recover and say that one drive appears healthy but it's corrupting data so you probably want to replace it
- iforgotpassword 1y ago
  Made that experience once ca. 2011. I hosted a Minecraft server ona box with raid1. The "cool" part was that I ran a cronjob that rendered the map to a png file once and hour, and at some point a friend asked why there were holes in the map. Back then, Minecraft stored every 16x16 chunk of the map in an individual gzipped file. When the raid1 decided to read the chunk from the bad drive, it couldn't unzip it. If that happened to the renderer, there was a hole on the map. If that happened to the game server, it would regenerate the chunk, and overwrite the old one on both drives, even the healthy one. Luckily as far a I remember that only happened on random terrain, otherwise someone would have ended up with half their house missing.
- iam-TJ 1y ago
  When using LVM one can use the dm-integrity target to detect data corruption.
  - dinosaurdynasty 1y ago
    You can even use it without LVM, though it's still a pain to setup.
- deleted 1y ago
  [deleted]
riedel 1y ago
Does someone know what the technology behind the tiering on QNAP NAS Systems is? I use an SSD RAID 1 in front of an RAID 10, which seems to work great. IMHO flexible tiering rather than caching would be very nice for many Systems as it is rather difficult to teach users to separate rather stale data from changing data. Often does not have to be perfect.
- rzzzt 1y ago
  Bcachefs supports both caching and tiering: https://wiki.archlinux.org/title/Bcachefs#SSD_caching https://wiki.archlinux.org/title/Bcachefs#SSD_caching A FUSE-based solution is autotier: https://github.com/45Drives/autotier https://github.com/45Drives/autotier
  - riedel 1y ago
    Looked at Autotier before, but the development looked pretty stale (which is not too bad per se if it is stable). Is there any experience/ recommendations with putting bcachefs also on top of networked block storage such as CEPH ? As CEPH SSD caching seems pretty deprecated by default, at work we looked at a solution to marry our HDD and SSD pool for users that do want to put too much thoughts into tiering by mount points.
    - magicalhippo 1y ago
      Will be interesting to play with. I used lvm cache to put ZFS on top of local NVMe for write-back caching of iSCSI targets, as ZFS has good built-in read caching. Worked pretty well in the limited tests I did, but it's not magic. Main reason I didn't pursue is that it felt a bit like a house of cards. Though on the positive side, one could always mount the underlying storage, ie partitions serving the iSCSI targets, as a local pool on another machine.
    - IcePic 1y ago
      You could use bcachefs on the OSD drives, but you can also just point the WAL/DB of the OSD to a partition on the ssd and have the data on hdd. You don't have to tier pools to get help with small writes/metadata using ssds.
evrennetwork 1y ago
[flagged]
rsync 1y ago
A reminder that zfs recently (past ~5 years) implemented dedicated metadata cache devices ... which allows you to cache either filesystem metadata or even small files to a blazing fast SSD mirror: https://www.rsync.net/resources/notes/2021-q3-rsync.net_technotes.html https://www.rsync.net/resources/notes/2021-q3-rsync.net_tech... This is a quick and easy way to add thousands of iops to even something very slow like a raidz3 zpool. As always: "Let's repeat, and emphasize: unlike an SLOG or L2ARC which are merely inconvenient to lose, if you lose your metadata vdev (your "special" vdev) you will lose your entire zpool just as surely as if you lost one of the other full vdevs ..."
- sitkack 1y ago
  I would hope ZFS has a way to mirror metadata from the pool into an ssd, so it is actually a cache but doesn't increase the probability of dataloss.
  - wongarsu 1y ago
    If you set up a normal L2arc (read cache device) that will cache both data and metadata. However you can configure it to only cache one of the two. Set it to metadata only and size it appropriately and you have basically a read-only metadata mirror. If you also want to have fast writes you can get a second SSD and set up a mirrored metadata device (storing metadata on mirrored SSDs, and regular data on whatever the rest of your pool uses)
    - Dylan16807 1y ago
      Last time I stapled l2arc onto a hard drive zfs it was still super slow to do things like ls large directories and the l2arc never filled more than a couple gigabytes. Maybe it works better now?
      - Filligree 1y ago
        It’s gotten smarter, and among other things no longer erases the cache on reboot. But for that specific case you should use a metadata vdev. Just make sure it’s mirrored!
Padriac 1y ago
RAID is great but without monitoring and alerting you can still have a problem. Better still is the automatic creation of incident records and escalation.
- slashdave 1y ago
  mdadm can be scripted using any ordinary system health monitoring system. On some servers I was responsible for, I had automatic monitoring setup configured to send e-mail the instant any drive failure was noticed. This is one of the nice things with open software. I can't imagine the trouble it would be to do the same for a proprietary raid card.
iam-TJ 1y ago
When using LVM there is no need to use separate mdadm (MD) based RAID - just use LVM's own RAID support. I have a workstation with four storage devices; two 512GB SSDs, one 1GB SSD, and one 3TB HDD. I use LUKS/dm_crypt for Full Disk Encryption (FDE) of the OS and most data volumes but two of the SSDs and the volumes they hold are unencrypted. These are for caching or public and ephemeral data that can easily be replaced: source-code of public projects, build products, experimental and temporary OS/VM images, and the like. dmsetup ls | wc -l reports 100 device-mapper Logical Volumes (LV). However only 30 are volumes exposing file-systems or OS images according to: ls -1 /dev/mapper/${VG}-* | grep -E "${VG}-[^_]+$" | wc -l The other 70 are LVM raid1 mirrors, writecache, crypt or other target-type volumes. This arrangement allows me to choose caching, raid, and any other device-mapper target combinations on a per-LV basis. I divide the file-system hierarchy into multiple mounted LVs and each is tailored to its usage, so I can choose both device-mapper options and file-system type. For example, /var/lib/machines/ is a LV with BTRFS to work with systemd-nspawn/machined so I have a base OS sub-volume and then various per-application snapshots based on it, whereas /home/ is RAID 1 mirror over multiple devices and /etc/ is also a RAID 1 mirror. The RAID 1 mirrors can be easily backed-up to remote hosts using iSCSI block devices. Simply add the iSCSI volume to the mirror as an additional member, allow it to sync 100%, and then remove it from the mirror (one just needs to be aware of and minimising open files when doing so - syncing on start-up or shutdown when users are logged out is a useful strategy or from the startup or shutdown initrd). Doing it this way rather than as file backups means in the event of disaster I can recover immediately on another PC simply by creating an LV RAID 1 with the iSCSI volume, adding local member volumes, letting the local volumes sync, then removing the iSCSI volume. I initially allocate a minimum of space to each volume. If a volume gets close to capacity - or runs out - I simply do a live resize using e.g: lvextend --resizefs --size +32G ${VG}/${LV} or, if I want to direct it to use a specific Physical Volume (PV) for the new space: lvextend --resizefs --size +32G ${VG}/${LV} ${PV} One has to be aware that --resizefs uses 'fsadmn' and only supports a limited set of file-systems (ext*, ReiserFS and XFS) so if using BTRFS or others their own resize operations are required, e.g: btrfs filesystem resize max /srv/NAS/${VG}/${LV}
- ecef9-8c0f-4374 1y ago
  Mdadm raid is rock solid. Lvm raid is not at the same level. There was a bug for years that made me doubt anybody even uses lvm-raids. I could not fix a broken raid without unmounting it. Mdadm and ext4 is what I use in production with all my trust. Lvm and btrfs for hobby projects.
whazor 1y ago
Theoretically, since you have three drives you want one drive to be with writeback. This way you could double the speed of your writes.
sneak 1y ago
One thing I’ve been doing lately is storing data on SSDs or raid0s of SSDs, then running continuous backups of changed files to a slow HDD. I don’t have single-transaction data safety requirements and the window in which I can lose data is very small, given that the backups run continuously. This is so much faster than these hyper-vigilant HA setups, too, while being quite a bit cheaper (the HDDs can be in a different box or building, or be Glacier, or whatever).
- LTL_FTC 1y ago
  By any chance, would you be willing to expand on your approach? What tools are using for this? How is it set up?
  - sneak 1y ago
    make a zfs temp snapshot, cd to snapshot dir, rsync it somewhere (usually rsync over ssh), cd out of snapshot dir, delete snapshot, do it again. it’s fairly easy to script. i usually run it via runit in /etc/service/realtimesync or such.
dale_glass 1y ago
LVM is a very cool thing that I feel is a bit underappreciated. I've always built my systems like this: two hard disks => RAID1 => LVM VG1. nvme => LVM VG2 Because at some point I decided LVM is just like flexible partitions and didn't pay much attention to the huge amounts of other stuff in the manpages. Turns out that's a pretty crappy way of doing things. LVM can do RAID, can deal with moving things across devices, and has many other fancy features. So instead of the above, stick it all into the same VG without RAID on top. You can RAID individual LVs. Some RAID1, some RAID5, some RAID0, some nothing, and pick on which disks stuff goes. You can add integrity checking which is not something MD RAID does. You can do caching. You can do writable snapshots. You can do thin provisioning. It's extremely flexible tech. The only thing I'd recommend staying away from is thin provisioning unless it's necessary. The performance impact is significant, virt-manager for some reason doesn't see thin LVs as legitimate disks (can be worked around easily though) and thin provisioning seems to be able to develop faults of its own. I've had one old setup where one block was somehow not readable and it seems to be a thin provisioning thing -- it doesn't say the underlying disk is bad, it's something more along the lines of the metadata being broken. To upgrade you can do things like moving LVs from one disk to another to free it up and remove it. Disks of different sizes are much less of a problem than with standard RAID, too.
- linsomniac 1y ago
  ~20 years ago I was helping someone with their storage server for their mail server, it had 8x 10K discs in a RAID-1. It was always struggling to keep up and often couldn't keep up. Intel had just come out with their SSDs, and I had a friend with access to one that was larger in size than the array. I shipped this little laptop drive off to get installed in the storage server. Once the SSD was on the server, I did a "pvmove" to move the data from spinning array to SSD, while the system was up and running. Over the next several hours the load on the server dropped. It was comical that these 8 hard drives could be replaced by something smaller than my wallet. But pvmove was the other star of this show.
  - MrDrMcCoy 1y ago
    If those drives were short-stroked, they probably could have kept up with that SSD, though at a reduced capacity. SSD would probably have a lower power bill over its life, though. I did some calculations for an array of short-stroked 15k SAS disks to replace a consumer 4GB SSD for a write-intensive app that chews through SSDs, and its performance would be in spitting distance of the SSD. Ended up not doing it due to likely not having any parts availability for 15k SAS drives in the not too distant future.
ndsipa_pomu 1y ago
I should try and do something like this. I've got lots of media stored on several large spinning rust drives and combine them using mergerfs (a union filesystem). However, I think I'd need something that caches at the file level rather than block devices, as I've got separate filesystems on the different disks. I got the idea of using mergerfs from this: https://perfectmediaserver.com/02-tech-stack/mergerfs/ https://perfectmediaserver.com/02-tech-stack/mergerfs/
- ThatPlayer 1y ago
  I use mergerfs too. I ended up with all the drives under mergerfs running on bcache with a single SSD as the cache. Mergerfs's documentations brings up ways to do tiered caching: https://trapexit.github.io/mergerfs/preview/usage_patterns/ https://trapexit.github.io/mergerfs/preview/usage_patterns/ . Though it doesn't really do a read cache. It only keeps the newest files on the SSDs. I hope bcachefs (not bcache) gets better. It supports combining multiple different slow drives like I do under mergerfs, and also a file level cache on SSDs. And even supports keeping metadata on the SSDs completely. Erasure coding isn't done yet either, so that's no replacement for SnapRAID.
thebeardisred 1y ago
This is a good writeup, but it's also missing the testing methodology (fio, a rsync job, etc) which allows one to understand the performance improvement quantitatively.
jpecar 1y ago
Been using lvm cache since about 2017 in high performance storage environment. Didn't like it much as it was too much of a blask box back then and didn't have any knobs to tune to adjust its behavior to the workload and we had plenty that didn't fit its logic. Ended up going full flash.
KaiserPro 1y ago
I have a special and burning hatred for mdadm and to a lesser extent LVM. I suspect that nowadays they are much easier to look after, but when I first was introduced, the quality of the documentation was utterly appalling. WE had special classes with old sysadmins who passed on the secret knowledge for how to not fuck everything with mdadm. LVM is slightly better, apart from the early false promise that was LVM snapshots which were essentially just a placebo(this might have changed now). I've only ever seen LVM used once successfully in production. That was on a 60 bad LFF raid draw to create a single namespace over 4 hardware raid-7 disk array things. Every other time it turn out to be a clusterfuck. ZFS if youre poor, GPFS if youre rich. I'm sure there are newer systems but they almost always fail ever the resilience, latency or performance test. (Cough gluster, ceph, anything that uses HTTP as a transport system)
oakwhiz 1y ago
I've got an LVM setup where the EFI boot stuff is triple RAID1 and the OS is on LVM with RAID5, but all other LVM volumes for data are selectively RAID0 or RAID5. It was not a fun experience to set up and it seems like certain actions could break it. But as long as it's respected it keeps going really well.
vanillax 1y ago
ZFS, Just use ZFS.

223 points by todsacerdoti 1y ago

Seems like there’s a very old trick we may have forgotten: put your WAL file on the fastest storage you have to speed up your database. I’d like to see benchmarks comparing both on the same hardware.

gopalv 1y ago

As always the YMMV of caching is access patterns, but the more consistent cacheable pattern has been the ext4 journals for me. They are tiny and often hit with a huge number of IOPS. Ext4 supported external journals and moving it to a single SSD for a large number of otherwise slow SMR disks has worked great in the past. However, when you hit a failure that SSD becomes a single root cause of data loss from several disks when losing that SSD (unlike a read cache). Where I was working that didn't matter as I was mostly working with HDFS which both likes a JBOD layout of several disks instead of RAID (no battery backed write caches), tolerant to a single node failing completely and having a ton more metadata operations thanks to writing a single large file as many fixed-size files named blk_<something> with a lot of directories containing thousands of files. SSDs were expensive then, but it's been a decade of getting cheaper from that.

trinsic2 1y ago
This reminds me of the hybrid drives. When the NVM failed its was a nightmare to deal with. IMHO it's a bad idea from a stability perspective to be caching off drive to Non-volatile memory.
- wtallis 1y ago
  Your last sentence does not follow from the preceding one. Hybrid drives were doomed by having truly tiny caches, making them not particularly fast (you need a lot of flash chips in parallel to get high throughput), prone to cache thrashing, and easy to wear out the NAND flash. These days, even if you try, it's hard to build a caching system that bad. There just aren't SSDs small and slow enough to have such a crippling effect. Even using a single consumer SSD as a cache for a full shelf of hard drives wouldn't be as woefully unbalanced as the SSHDs that tried to get by with only 8GB of NAND.
GauntletWizard 1y ago
The same for ZFS; there's provisioning to make a "zil" device - ZFS Intent Log, basically the journal. ZFS is a little nicer in that this journal is explicitly disposable - If you lose your ZIL device, you lose any writes since it's horizon, but you don't lose the whole array. The next step up is building a "metadata" device, which stores the filesystem metadata but not data. This is dangerous in the way the ext4 journal is; lose the metadata, and you lose everything. Both are massive speedups. When doing big writes, a bunch of spinning rust can't achieve full throughput without a SSD ZIL. My 8+2 array can write nearly two gigabits, but it's abysmal (roughly the speed of a single drive) without a ZIL. Likewise, a metadata device can make the whole filesystem feel as snappy as SSD, but it's unnecessary if you have enough cache space; ZFS prefers it, so if your metadata fits into your cache SSD, most of it will stay loaded
- Szpadel 1y ago
  I just want to mention that ZIL is just to speed up sync writes, as it ends syscall when data are written to ZIL, but might be still in progress on slower storage. ZIL is also basically write only storage, therefore sad without very significant over provisioning will die quickly (you only read from ZIL after unclean shutdown) if you don't really case about latest version of file (risk of loosing recent chances is acceptable) you might set sync=disabled for that dataset and you can have great performance without ZIL
  - magicalhippo 1y ago
    Minor nitpick, your post is primarily talking about SLOG, separate intent log. The pool always has a ZIL, but you can put it on a separate device, or decices, with SLOG[1]. [1]: https://www.truenas.com/docs/references/zilandslog/ https://www.truenas.com/docs/references/zilandslog/
- JonChesterfield 1y ago
  There's a configuration option that amounts to putting a directory (or maybe a volume) entirely into the metadata drive. It's been a long time since I set that up, but the home storage has spinning rust plus a raid 1 of crucial ssd (sata! But ones with a capacitor to hopefully handle writes after power loss), where the directory I care about performance for lives on the ssd subarray. Still presents as one blob of storage. Metadata on the ssd too, probably no ZIL but could be wrong about that. Made ls a lot more reasonable. Thinking about it that system must be trundling towards expected death, it might be a decade old now.
Dylan16807 1y ago
> However, when you hit a failure that SSD becomes a single root cause of data loss from several disks when losing that SSD (unlike a read cache). In theory you can massively reduce this risk by keeping a copy of the journal in memory so it only corrupts if you have a disk loss and a power outage within a few seconds of each other. But I don't know if the tools available would let you do that properly.
hinkley 1y ago
Twin SSDs and RAID 1.

bjt12345 1y ago

Oh I miss Optane drives.

dur-randir 1y ago
Grab one from Aliexpress while you stil can)

ggm 1y ago

The logic for not zfs cited reduces to two things: FUD and not in baseline Linux. The pro case for BTRFS is being able to do JBOD with a bit of additional comfort around mirror state over drives.

dangus 1y ago
Yeah I really didn’t understand why ZFS or something like a TrueNAS dedicated storage solution setup was ruled out so quickly. But before we even go there, we have to consider an all-SSD solution. SSDs are so cheap nowadays. It’s a trivial cost to buy a 2-4TB SSD. Heck, even an 8TB SSD is reasonably affordable, only about $600. So first step is justifying a complicated caching setup. Why cache at all when you can just use all SSD storage and bring the complexity down a whole lot? And if you’re using more than 2-8TB of storage and you’re in the spinning disk territory, why are you not using a dedicated NAS solution like TrueNAS? This solution just seems like one of the worst possible choices.
- dur-randir 1y ago
  I have a 100TB array setup with LVM. I've thought (twice, each time I expanded this array) about using ZFS. It was ruled out for three things: - there had been no raidz expansion (but now is, so this point is crossed) - ZFS degrades read latency with the number of drives in array, while mdraid/lvm scales linearly - this is the price you pay for your checksums - write-cache options on ZFS are atrotious, ZIL/SLOG are nothing compared to dm_writecache - I can stream 2GB/s full of sync writes until my cache drive is filled up, and it also provides reads to freshly written data, without going to backing pool So, saying "why not ZFS" or "go buy some SSDs" is not really productive for promoting ZFS - it just underscores that "for ZFS" crowd are zealots.
  - ggm 1y ago
    Maybe I skimmed too fast, but I didn't see your criticisms in the write up cited. They're a good critique, ssd aside: ssd are magic, any filesystem. ZFS mainline kernel aside, is the only FS I've seen which is able to encompass redundancy and is portable BSD <-> Linux. It isn't a big reason I run it, but it's one of them. Snapshotting is the big reason although the various journal fs had this ages ago. I don't personally feel a zealot, but I admit to proselytising.

Szpadel 1y ago

something that people forget with raid1 is that this only protect from catastrophic disk failure. this means your your drive need to be dead for raid to do it's protection and this is usually the case. the problem is when starts corrupting data it reads of writes. in that case raid have no way to know that and can even corrupt data on the healthy drive. (data is read corrupted and then written to both drives) the issue is that there are 2 copies of the data and raid have no way of telling with one is correct so it's basically flips a coin and select one of them, even if filesystem knows that content makes no sense. that's basically biggest advantage of filesystems like zfs or btrfs that manage raid themselves, they have checksums and that know with copy is valid and are able to recover and say that one drive appears healthy but it's corrupting data so you probably want to replace it

iforgotpassword 1y ago
Made that experience once ca. 2011. I hosted a Minecraft server ona box with raid1. The "cool" part was that I ran a cronjob that rendered the map to a png file once and hour, and at some point a friend asked why there were holes in the map. Back then, Minecraft stored every 16x16 chunk of the map in an individual gzipped file. When the raid1 decided to read the chunk from the bad drive, it couldn't unzip it. If that happened to the renderer, there was a hole on the map. If that happened to the game server, it would regenerate the chunk, and overwrite the old one on both drives, even the healthy one. Luckily as far a I remember that only happened on random terrain, otherwise someone would have ended up with half their house missing.
iam-TJ 1y ago
When using LVM one can use the dm-integrity target to detect data corruption.
- dinosaurdynasty 1y ago
  You can even use it without LVM, though it's still a pain to setup.
deleted 1y ago
[deleted]

riedel 1y ago

Does someone know what the technology behind the tiering on QNAP NAS Systems is? I use an SSD RAID 1 in front of an RAID 10, which seems to work great. IMHO flexible tiering rather than caching would be very nice for many Systems as it is rather difficult to teach users to separate rather stale data from changing data. Often does not have to be perfect.

rzzzt 1y ago
Bcachefs supports both caching and tiering: https://wiki.archlinux.org/title/Bcachefs#SSD_caching https://wiki.archlinux.org/title/Bcachefs#SSD_caching A FUSE-based solution is autotier: https://github.com/45Drives/autotier https://github.com/45Drives/autotier
- riedel 1y ago
  Looked at Autotier before, but the development looked pretty stale (which is not too bad per se if it is stable). Is there any experience/ recommendations with putting bcachefs also on top of networked block storage such as CEPH ? As CEPH SSD caching seems pretty deprecated by default, at work we looked at a solution to marry our HDD and SSD pool for users that do want to put too much thoughts into tiering by mount points.
  - magicalhippo 1y ago
    Will be interesting to play with. I used lvm cache to put ZFS on top of local NVMe for write-back caching of iSCSI targets, as ZFS has good built-in read caching. Worked pretty well in the limited tests I did, but it's not magic. Main reason I didn't pursue is that it felt a bit like a house of cards. Though on the positive side, one could always mount the underlying storage, ie partitions serving the iSCSI targets, as a local pool on another machine.
  - IcePic 1y ago
    You could use bcachefs on the OSD drives, but you can also just point the WAL/DB of the OSD to a partition on the ssd and have the data on hdd. You don't have to tier pools to get help with small writes/metadata using ssds.

evrennetwork 1y ago

[flagged]

rsync 1y ago

A reminder that zfs recently (past ~5 years) implemented dedicated metadata cache devices ... which allows you to cache either filesystem metadata or even small files to a blazing fast SSD mirror: https://www.rsync.net/resources/notes/2021-q3-rsync.net_technotes.html https://www.rsync.net/resources/notes/2021-q3-rsync.net_tech... This is a quick and easy way to add thousands of iops to even something very slow like a raidz3 zpool. As always: "Let's repeat, and emphasize: unlike an SLOG or L2ARC which are merely inconvenient to lose, if you lose your metadata vdev (your "special" vdev) you will lose your entire zpool just as surely as if you lost one of the other full vdevs ..."

sitkack 1y ago
I would hope ZFS has a way to mirror metadata from the pool into an ssd, so it is actually a cache but doesn't increase the probability of dataloss.
- wongarsu 1y ago
  If you set up a normal L2arc (read cache device) that will cache both data and metadata. However you can configure it to only cache one of the two. Set it to metadata only and size it appropriately and you have basically a read-only metadata mirror. If you also want to have fast writes you can get a second SSD and set up a mirrored metadata device (storing metadata on mirrored SSDs, and regular data on whatever the rest of your pool uses)
  - Dylan16807 1y ago
    Last time I stapled l2arc onto a hard drive zfs it was still super slow to do things like ls large directories and the l2arc never filled more than a couple gigabytes. Maybe it works better now?
    - Filligree 1y ago
      It’s gotten smarter, and among other things no longer erases the cache on reboot. But for that specific case you should use a metadata vdev. Just make sure it’s mirrored!

Padriac 1y ago

RAID is great but without monitoring and alerting you can still have a problem. Better still is the automatic creation of incident records and escalation.

slashdave 1y ago
mdadm can be scripted using any ordinary system health monitoring system. On some servers I was responsible for, I had automatic monitoring setup configured to send e-mail the instant any drive failure was noticed. This is one of the nice things with open software. I can't imagine the trouble it would be to do the same for a proprietary raid card.

iam-TJ 1y ago

When using LVM there is no need to use separate mdadm (MD) based RAID - just use LVM's own RAID support. I have a workstation with four storage devices; two 512GB SSDs, one 1GB SSD, and one 3TB HDD. I use LUKS/dm_crypt for Full Disk Encryption (FDE) of the OS and most data volumes but two of the SSDs and the volumes they hold are unencrypted. These are for caching or public and ephemeral data that can easily be replaced: source-code of public projects, build products, experimental and temporary OS/VM images, and the like. dmsetup ls | wc -l reports 100 device-mapper Logical Volumes (LV). However only 30 are volumes exposing file-systems or OS images according to: ls -1 /dev/mapper/${VG}-* | grep -E "${VG}-[^_]+$" | wc -l The other 70 are LVM raid1 mirrors, writecache, crypt or other target-type volumes. This arrangement allows me to choose caching, raid, and any other device-mapper target combinations on a per-LV basis. I divide the file-system hierarchy into multiple mounted LVs and each is tailored to its usage, so I can choose both device-mapper options and file-system type. For example, /var/lib/machines/ is a LV with BTRFS to work with systemd-nspawn/machined so I have a base OS sub-volume and then various per-application snapshots based on it, whereas /home/ is RAID 1 mirror over multiple devices and /etc/ is also a RAID 1 mirror. The RAID 1 mirrors can be easily backed-up to remote hosts using iSCSI block devices. Simply add the iSCSI volume to the mirror as an additional member, allow it to sync 100%, and then remove it from the mirror (one just needs to be aware of and minimising open files when doing so - syncing on start-up or shutdown when users are logged out is a useful strategy or from the startup or shutdown initrd). Doing it this way rather than as file backups means in the event of disaster I can recover immediately on another PC simply by creating an LV RAID 1 with the iSCSI volume, adding local member volumes, letting the local volumes sync, then removing the iSCSI volume. I initially allocate a minimum of space to each volume. If a volume gets close to capacity - or runs out - I simply do a live resize using e.g: lvextend --resizefs --size +32G ${VG}/${LV} or, if I want to direct it to use a specific Physical Volume (PV) for the new space: lvextend --resizefs --size +32G ${VG}/${LV} ${PV} One has to be aware that --resizefs uses 'fsadmn' and only supports a limited set of file-systems (ext*, ReiserFS and XFS) so if using BTRFS or others their own resize operations are required, e.g: btrfs filesystem resize max /srv/NAS/${VG}/${LV}

ecef9-8c0f-4374 1y ago
Mdadm raid is rock solid. Lvm raid is not at the same level. There was a bug for years that made me doubt anybody even uses lvm-raids. I could not fix a broken raid without unmounting it. Mdadm and ext4 is what I use in production with all my trust. Lvm and btrfs for hobby projects.

whazor 1y ago

Theoretically, since you have three drives you want one drive to be with writeback. This way you could double the speed of your writes.

sneak 1y ago

One thing I’ve been doing lately is storing data on SSDs or raid0s of SSDs, then running continuous backups of changed files to a slow HDD. I don’t have single-transaction data safety requirements and the window in which I can lose data is very small, given that the backups run continuously. This is so much faster than these hyper-vigilant HA setups, too, while being quite a bit cheaper (the HDDs can be in a different box or building, or be Glacier, or whatever).

LTL_FTC 1y ago
By any chance, would you be willing to expand on your approach? What tools are using for this? How is it set up?
- sneak 1y ago
  make a zfs temp snapshot, cd to snapshot dir, rsync it somewhere (usually rsync over ssh), cd out of snapshot dir, delete snapshot, do it again. it’s fairly easy to script. i usually run it via runit in /etc/service/realtimesync or such.

dale_glass 1y ago

LVM is a very cool thing that I feel is a bit underappreciated. I've always built my systems like this: two hard disks => RAID1 => LVM VG1. nvme => LVM VG2 Because at some point I decided LVM is just like flexible partitions and didn't pay much attention to the huge amounts of other stuff in the manpages. Turns out that's a pretty crappy way of doing things. LVM can do RAID, can deal with moving things across devices, and has many other fancy features. So instead of the above, stick it all into the same VG without RAID on top. You can RAID individual LVs. Some RAID1, some RAID5, some RAID0, some nothing, and pick on which disks stuff goes. You can add integrity checking which is not something MD RAID does. You can do caching. You can do writable snapshots. You can do thin provisioning. It's extremely flexible tech. The only thing I'd recommend staying away from is thin provisioning unless it's necessary. The performance impact is significant, virt-manager for some reason doesn't see thin LVs as legitimate disks (can be worked around easily though) and thin provisioning seems to be able to develop faults of its own. I've had one old setup where one block was somehow not readable and it seems to be a thin provisioning thing -- it doesn't say the underlying disk is bad, it's something more along the lines of the metadata being broken. To upgrade you can do things like moving LVs from one disk to another to free it up and remove it. Disks of different sizes are much less of a problem than with standard RAID, too.

linsomniac 1y ago
~20 years ago I was helping someone with their storage server for their mail server, it had 8x 10K discs in a RAID-1. It was always struggling to keep up and often couldn't keep up. Intel had just come out with their SSDs, and I had a friend with access to one that was larger in size than the array. I shipped this little laptop drive off to get installed in the storage server. Once the SSD was on the server, I did a "pvmove" to move the data from spinning array to SSD, while the system was up and running. Over the next several hours the load on the server dropped. It was comical that these 8 hard drives could be replaced by something smaller than my wallet. But pvmove was the other star of this show.
- MrDrMcCoy 1y ago
  If those drives were short-stroked, they probably could have kept up with that SSD, though at a reduced capacity. SSD would probably have a lower power bill over its life, though. I did some calculations for an array of short-stroked 15k SAS disks to replace a consumer 4GB SSD for a write-intensive app that chews through SSDs, and its performance would be in spitting distance of the SSD. Ended up not doing it due to likely not having any parts availability for 15k SAS drives in the not too distant future.

ndsipa_pomu 1y ago

I should try and do something like this. I've got lots of media stored on several large spinning rust drives and combine them using mergerfs (a union filesystem). However, I think I'd need something that caches at the file level rather than block devices, as I've got separate filesystems on the different disks. I got the idea of using mergerfs from this: https://perfectmediaserver.com/02-tech-stack/mergerfs/ https://perfectmediaserver.com/02-tech-stack/mergerfs/

ThatPlayer 1y ago
I use mergerfs too. I ended up with all the drives under mergerfs running on bcache with a single SSD as the cache. Mergerfs's documentations brings up ways to do tiered caching: https://trapexit.github.io/mergerfs/preview/usage_patterns/ https://trapexit.github.io/mergerfs/preview/usage_patterns/ . Though it doesn't really do a read cache. It only keeps the newest files on the SSDs. I hope bcachefs (not bcache) gets better. It supports combining multiple different slow drives like I do under mergerfs, and also a file level cache on SSDs. And even supports keeping metadata on the SSDs completely. Erasure coding isn't done yet either, so that's no replacement for SnapRAID.

thebeardisred 1y ago

This is a good writeup, but it's also missing the testing methodology (fio, a rsync job, etc) which allows one to understand the performance improvement quantitatively.

jpecar 1y ago

Been using lvm cache since about 2017 in high performance storage environment. Didn't like it much as it was too much of a blask box back then and didn't have any knobs to tune to adjust its behavior to the workload and we had plenty that didn't fit its logic. Ended up going full flash.

KaiserPro 1y ago

I have a special and burning hatred for mdadm and to a lesser extent LVM. I suspect that nowadays they are much easier to look after, but when I first was introduced, the quality of the documentation was utterly appalling. WE had special classes with old sysadmins who passed on the secret knowledge for how to not fuck everything with mdadm. LVM is slightly better, apart from the early false promise that was LVM snapshots which were essentially just a placebo(this might have changed now). I've only ever seen LVM used once successfully in production. That was on a 60 bad LFF raid draw to create a single namespace over 4 hardware raid-7 disk array things. Every other time it turn out to be a clusterfuck. ZFS if youre poor, GPFS if youre rich. I'm sure there are newer systems but they almost always fail ever the resilience, latency or performance test. (Cough gluster, ceph, anything that uses HTTP as a transport system)

oakwhiz 1y ago

I've got an LVM setup where the EFI boot stuff is triple RAID1 and the OS is on LVM with RAID5, but all other LVM volumes for data are selectively RAID0 or RAID5. It was not a fun experience to set up and it seems like certain actions could break it. But as long as it's respected it keeps going really well.

vanillax 1y ago

ZFS, Just use ZFS.