6 ms·

Does ZFS do anything to optimize for SSDs?

• wmf 16y ago
  L2ARC lets you use SSD as a disk cache. I wonder how well it works with an SD card in a MBP...
  • jonhohle 16y ago
    Newer Macs use PCI-E for the SD card interface, so it could potentially work, though you'd need a very fast SD card sticking out the side of your Mac all the time.
• esteth 16y ago
  AFAIK, ZFS does copy-on-write updates, so that's a slight form of wear levelling. So yes it does, but unintentionally.
• ghaff 16y ago
  Yes. ZFS has the concept of storage pools--what used to be called hierarchical storage management. So it can deal explicitly with storage in which some members of the pool, e.g. SSDs, are faster than others. However, this is basically a server concept. It has very little to do with how MacBooks might be used.
• dprice1 16y ago
  There are three ways you can use SSDs with ZFS. First, you can use SSDs in place of rotating rust. Second, as was previously mentioned, you can use an SSD as an extension of your filesystem cache. That's called Level-2 Adaptive Replacement Cache (L2ARC). You can also use an SSD as a logging disk to accelerate writes; that's called "Logzilla", IIRC. In commercial offerings built around these features, you typically source an SSD that is either write-biased (logzilla) or read-biased, depending on what you are trying to do.
  • zdw 16y ago
    Just some formal clarifications: Logzilla's formal name is ZIL, ZFS Intent Log. Generally these are SLC flash SSD's, mirrored as losing the ZIL on a ZFS pool can lead to "interesting" recovery situations. L2ARC is basically an extension of main memory used to cache data from the drives. If you lose L2ARC, there aren't any serious consequences. Usually L2ARC is implemented with less expensive MLC flash SSD's. On a related note, Seagate sells a Hybrid SSD+rust drive called the Momentus XT which uses it's 4GB of flash a similar manner to the L2ARC.
    • ssmoot 16y ago
      I'm pretty sure the ZIL is not mirrored. If it were, it wouldn't increase performance since you'd still have to wait for the disks to fsync their copy to guarantee reliability. This is why Sun Storage products (and Nexenta, or homegrown clusters) put the ZIL SSDs in the JBODs and not the storage heads. You could of-course create a pool that did use a disk as the ZIL, but again, there'd be no point since the mirror has to be kept consistent otherwise it's worthless. Since the cache (L2ARC) is just cache, and you can lose it at anytime without data-loss, it is in the heads. Nit-picking. To be clear, the ZIL can (and should be) mirrored, you just want to do it with SSDs consistently. Mixing devices is possible, but you'll be limited to the performance of the slowest device. You can also create storage clusters with multiple heads. Again, a good idea IMO, but the ZIL is a critical component of the FS. If you lose it, you lose the whole pool (as a rule I think, but there might be clever hacks around that under special circumstances if you're lucky). So if you're going to multi-home your zpool, make sure the ZILs are in the shared-storage region. It's no good having redundant controllers if your ZIL is on the dead one.
• Andys 16y ago
  Its data dedupe feature is only really fast enough to use on SSDs
  • ssmoot 16y ago
    It also takes a lot of RAM. 380 bytes for each de-dupe entry (block pointer) IIRC? I think it translated to something like 1GB of RAM per TB of storage assuming half of it was de-duped. It's really a useless feature when you do the math. Unless you're running a small amount of storage with a very VERY large amount of basically identical volumes (think Amazon) you'll spend more on memory than you did on disk and once you get to that point you'd have almost certainly been better off spending that money on SSDs and using any extra memory for primary cache.
    • Andys 16y ago
      Thats my point - its very useful with SSDs, because you don't need all the RAM, because SSD is so fast at random seek.
      • ssmoot 16y ago
        I forget the exact names, but go with it. :-) ZFS has two tables: A Block Pointer Table. This is your hashes of blocks and stays in RAM to let you know where on disk you'll find a particular block. It's also referenced during writing to ensure that the COW operations are transactional. The DDT (DataDedupeTable) is similar, but points to de-duped blocks. You need enough RAM to keep this in memory at all times. Otherwise for every write you'll have to scan through the entire table on disk, find matching blocks, then modify it. You'll also have to scan through it for every read to see if the block you're looking for is de-duped. I've probably mixed up the details. I haven't read the source, just used it. But that's my (maybe flawed) understanding of how it works. Bottom line though, you DO need enough RAM to keep the DDT in memory. If you don't you'll see SEVERE thrashing and SSD or no SSD your disk performance will slow down from thousands of IOPS to tens of IOPS or lower. This exact thing happened to us with Sun's 7310, loaded with the Sun specified SSDs. You need to be very sure you have the hardware for de-dupe, and even then the payoff is so small... The only real use-case I can think of is if you're running a VPS.