4 ms·

There's a bunch of pretty simple, old products for using SSD's to provided caching for higher latency drives that are all about ~a decade old. Some of them even

There's a bunch of pretty simple, old products for using SSD's to provided caching for higher latency drives that are all about ~a decade old. Some of them even use Linux's device manager or the block device subsystem explicitly... https://github.com/mingzhao/dm-cache https://github.com/mingzhao/dm-cache https://man7.org/linux/man-pages/man7/lvmcache.7.html https://man7.org/linux/man-pages/man7/lvmcache.7.html https://www.kernel.org/doc/Documentation/bcache.txt https://www.kernel.org/doc/Documentation/bcache.txt https://github.com/facebookarchive/flashcache https://github.com/facebookarchive/flashcache https://github.com/stec-inc/EnhanceIO https://github.com/stec-inc/EnhanceIO Doing RAID-1 (or RAID-10) style solution certainly is reasonable, but I don't understand what's novel here. ...and IIRC this is the kind of thing that btrfs and zfs were managing explicitly...

ecnahc515 4y ago
They literally mentioned the first 3 in the blog post. They said the issue with all of them was related to handling of bad sectors on the SSDs.
- cbsmith 4y ago
  Yeah, I saw that. Given their "solve" though, this seems like an odd place they ended up no? They're going to have redundant copies on other machines the ScyllaDB anyway (which also has its own caching mechanism), so a failure on a read isn't that catastrophic (and in the cloud, you just spin up a new node and terminate the old one... something ScyllaDB handles very gracefully).
  - withinboredom 4y ago
    Yeah, I was thinking about this too. If you have to restore on a new node anyway, why have the persistent store anyway. The only reasonable answer I could think of was if they lost the whole data enter to a fire or something. They’d be able to restore the data in another zone, but that assumes they are using replicated persistent storage, which they didn’t mention. If the data isn’t replicated to another zone, this solution doesn’t make any sense.

ecnahc515 4y ago

They literally mentioned the first 3 in the blog post. They said the issue with all of them was related to handling of bad sectors on the SSDs.

cbsmith 4y ago
Yeah, I saw that. Given their "solve" though, this seems like an odd place they ended up no? They're going to have redundant copies on other machines the ScyllaDB anyway (which also has its own caching mechanism), so a failure on a read isn't that catastrophic (and in the cloud, you just spin up a new node and terminate the old one... something ScyllaDB handles very gracefully).
- withinboredom 4y ago
  Yeah, I was thinking about this too. If you have to restore on a new node anyway, why have the persistent store anyway. The only reasonable answer I could think of was if they lost the whole data enter to a fire or something. They’d be able to restore the data in another zone, but that assumes they are using replicated persistent storage, which they didn’t mention. If the data isn’t replicated to another zone, this solution doesn’t make any sense.