Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

HSE: Heterogeneous-memory storage engine designed for SSDs

github.com

Post reply on HN
Print view View original

41–47 of 47 posts

Re: HSE: Heterogeneous-memory storage engine designed for SSDs

#41

Post by wtallis »

shockinglytrue wrote: post #6

Much better link: https://github.com/hse-project/hse PR is insane hot air referring to another hot air product (can you even buy their 3D Xpoint devices yet?)

> can you even buy their 3D Xpoint devices yet?

Nope. The only product they've announced so far using 3D XPoint is the Micron X100 SSD, which they're only selling to a limited number of major customers; you won't find it for sale on CDW. Intel's Optane products do use 3D XPoint memory, and at the moment I believe that's all manufactured in a Micron-owned fab. (Intel used to co-own it, and I don't think Intel will have their own production line up and running until next year.)

Re: HSE: Heterogeneous-memory storage engine designed for SSDs

#42

Post by wtallis »

haneefmubarak wrote: post #4

Looks pretty cool when you make it to the GitHub ( https://github.com/hse-project ). Order of magnitude performance gains! I imagine most of that come from skipping the Filesystem layer and just hitting the raw Block layer directly. I am curious about the durability and how well tested all of that is though. On the one hand, filesystems put a lot of work towards ensuring that bytes written to disk and synced are most…

> I am curious about the durability and how well tested all of that is though. On the one hand, filesystems put a lot of work towards ensuring that bytes written to disk and synced are most likely durable,

All of the SSDs that this software might be deployed to have power loss protection capacitors to ensure the drive can flush its write caches when necessary. So this software only needs to make sure that the OS actually sends data to the drive instead of holding it back in an IO scheduler queue (as you point out, they're already bypassing the FS layer). Since this software should be pretty good at structuring its writes in an SSD-friendly pattern, the operating system's IO scheduler should probably just be disabled.

Re: HSE: Heterogeneous-memory storage engine designed for SSDs

#43

Post by polskibus »

andromeduck wrote: post #34
haneefmubarak wrote: post #4

Looks pretty cool when you make it to the GitHub ( https://github.com/hse-project ). Order of magnitude performance gains! I imagine most of that come from skipping the Filesystem layer and just hitting the raw Block layer directly. I am curious about the durability and how well tested all of that is though. On the one hand, filesystems put a lot of work towards ensuring that bytes written to disk and synced are most…

SSDs are already raid devices internally so they're really no point as whatever you can do the vendor can and do faster and better in hardware/firmware. That's why all the hyperscalers all have their own custom SKUs.

could you elaborate? how can a standard user achieve improvements on their own? what's changed in those custom SKU?

Re: HSE: Heterogeneous-memory storage engine designed for SSDs

#44

Post by xnyan »

polskibus wrote: post #43
andromeduck wrote: post #34

Earlier quoted context omitted.

SSDs are already raid devices internally so they're really no point as whatever you can do the vendor can and do faster and better in hardware/firmware. That's why all the hyperscalers all have their own custom SKUs.

could you elaborate? how can a standard user achieve improvements on their own? what's changed in those custom SKU?

Are you asking how to design a custom hardware raid controller, then tune it to match the performance characteristics of the specific NAND chips you have? Seems outside of the range of most people's abilities.

Re: HSE: Heterogeneous-memory storage engine designed for SSDs

#45

Post by continuations »

benlwalker wrote: post #26
aloknnikhil wrote: post #12

> https://github.com/hse-project/hse Their benchmarks show significant gains compared to RocksDB. > https://github.com/spdk/rocksdb But what I'd really like to see is a comparison against RocksDB using SPDK > https://dqtibwqq6s6ux.cloudfront.net/download/papers/Hitachi... Based on these results, SPDK performs significantly better than the kernel requiring only 1-2 cores to saturate IOPS on an NVMe SSD (compared to th…

SPDK's RocksDB integration really hasn't gotten a lot of love. There's really two main challenges we hit and then never revisited. First, the IO threads in RocksDB are a thread pool that assume they perform blocking operations. That doesn't jive with SPDK's async model (nor io_uring's). We're having to message pass to an async thread and block on semaphores in the IO threads. Second, RocksDB was heavily reliant on th…

The SPDK RocksDB repo (https://github.com/spdk/rocksdb) seems to have been abandoned (last commit 2017).

Is there a maintained version of SPDK RocksDB? Or SPDK any DB?

Re: HSE: Heterogeneous-memory storage engine designed for SSDs

#46

Post by ignoramous »

wtallis wrote: post #42
haneefmubarak wrote: post #4

Looks pretty cool when you make it to the GitHub ( https://github.com/hse-project ). Order of magnitude performance gains! I imagine most of that come from skipping the Filesystem layer and just hitting the raw Block layer directly. I am curious about the durability and how well tested all of that is though. On the one hand, filesystems put a lot of work towards ensuring that bytes written to disk and synced are most…

> I am curious about the durability and how well tested all of that is though. On the one hand, filesystems put a lot of work towards ensuring that bytes written to disk and synced are most likely durable, All of the SSDs that this software might be deployed to have power loss protection capacitors to ensure the drive can flush its write caches when necessary. So this software only needs to make sure that the OS actu…

> ...the operating system's IO scheduler should probably just be disabled.

The default on RHEL/Fedora has long been the noop scheduler. I'd be surprised if other distributions haven't followed suit, given the prevalence of SSDs.

Re: HSE: Heterogeneous-memory storage engine designed for SSDs

#47

Post by ignoramous »

sahil-kang wrote: post #28
organicfigs wrote: post #23

Someone needs to write a book about breaking into writing software like RocksDB, HSE, etc. Years ago I found myself wanting to learn more however going from 0 to 1 felt impossible. Graduated from a T3 school in CS so understanding the concepts wasn't the issue, I just didn't know how to build a good foundation in low latency persistence. Years later I ended up contributing to low latency java which was really interes…

I just finished reading the OSTEP book[1] and it has a nice chapter on SSDs[2]. The entire last portion of the book is about filesystems/disks so you might find it interesting. [1] http://pages.cs.wisc.edu/~remzi/OSTEP/ [2] http://pages.cs.wisc.edu/~remzi/OSTEP/file-ssd.pdf

> pages.cs.wisc.edu/~remzi/OSTEP

I see a maintenance page instead:

"Sorry! The URL you requested was not found on our server.

Is it Sunday between 4 and 8 PM (CST)? If so, the server may be undergoing regularly scheduled downtime. Otherwise, please contact the maintainer of the referring page and ask them to fix their link. Thanks!"

Here's a Jan, 2020 snapshot: https://web.archive.org/web/20200122013800/https://pages.cs....

Post reply on HN