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

Modern storage is plenty fast, but the APIs are bad

itnext.io

Post reply on HN
Print view View original

31–40 of 168 posts

Re: Modern storage is plenty fast, but the APIs are bad

#31

Post by dfinninger »

blindm wrote: post #15
tjoff wrote: post #6

Earlier quoted context omitted.

The solution for this problem is raid. Way cheaper and far superior in terms of reliability than your solution. Or if that isn't an option (laptop?) a good backup-solution that that runs daily or more often is also a better and cheaper alternative. Drives may dail at any time, but they don't age the way your post would suggest.

I've looked into RAID. It seems a bit complicated to use. Is it trivial to create a RAID array in Linux with zero fuss and the whole thing 'just working' with very little knowledge of the filesystem itself other than it keeps your data 'safe' and redundancy baked in?

Do you mean “use” or “setup”? RAID is trivial to use. Mount the volume to a directory and use it like normal.

The setup is a bit more involved, but really not that bad. It’s a couple commands to join a few disks in an array and then you make a file system and mount it.

https://www.digitalocean.com/community/tutorials/how-to-crea...

Re: Modern storage is plenty fast, but the APIs are bad

#32

Post by mehrdadn »

I liked most of the piece, but some bits rubbed me the wrong way:

> I was taken by surprise by the fact that although every one of my peers is certainly extremely bright, most of them carried misconceptions about how to best exploit the performance of modern storage technology leading to suboptimal designs, even if they were aware of the increasing improvements in storage technology.

> In the process of writing this piece I had the immense pleasure of getting early access to one of the next generation Optane devices, from Intel.

The entire blog post is complaining about how great engineers have misconception about modern storage technology and yet to prove it the author had to obtain benchmarks from early access to next-generation devices...?! And to top it off, from this we conclude "the disconnect" is due to the APIs? Not, say, from the possibility that such blazing-fast components may very well not even exist in users' devices? I'm not saying the conclusions are wrong, but the logic surely doesn't follow... and honestly it's a little tasteless to criticize people's understanding if you're going to base the criticism on things they in all likelihood don't even have access to.

Re: Modern storage is plenty fast, but the APIs are bad

#33

Post by Blahah »

zbrozek wrote: post #11
blindm wrote: post #4

Also: Modern storage is plenty fast, but also not reliable for long term use. That is why I buy a new SSD every year and clone my current (worn out) SSD to the new one. I have several old SSDs that started to get unhealthy, well, according to my S.M.A.R.T utility that I used to check them. I could probably get away with using an SSD for another year, but will not risk the data loss. Anyone else do this?

What do you do that wears them out so fast? I've been running the same NVMe disk as my daily driver since 2015 and it's not showing any signs of degradation.

I work with bioinformatics data and tend to switch out an NVMe within 3-4 months. I'm usually maxing out read or write for 12 out of 24 hours a day. The slowdown is rapid and very noticeable.

Re: Modern storage is plenty fast, but the APIs are bad

#34

Post by rcxdude »

jeroenhd wrote: post #29

I suppose _modern_ storage is fast, but how many servers are running on storage this modern? None of mine are and my work dev machine is still rocking a SATA 2.5" SSD. We're probably still a few years off from being able to switch to this fast I/O yet. With the new game consoles switching over to PCIe SSDs I expect the price of NVMe drives to drop over the next few years until they're cheap enough that the majority o…

Well, if the whole async 'I/O is the bottleneck' principle which was the refrain from a few years ago is actually true, then servers running databases should be focusing on upgrading their storage to these levels, since that's where the most bang for buck comes from in terms of performance gain is (of course now the big thing is running everything on clouds like AWS where everything is dog slow and really expensive, so perhaps it doesn't actually matter). (In fact the main reason for the API changes covered in the article is because the CPU and RAM can no longer run laps around storage).

Re: Modern storage is plenty fast, but the APIs are bad

#35

Post by scribu »

jeroenhd wrote: post #29

I suppose _modern_ storage is fast, but how many servers are running on storage this modern? None of mine are and my work dev machine is still rocking a SATA 2.5" SSD. We're probably still a few years off from being able to switch to this fast I/O yet. With the new game consoles switching over to PCIe SSDs I expect the price of NVMe drives to drop over the next few years until they're cheap enough that the majority o…

> how many servers are running on storage this modern?

AWS allows you to provision EC2 instances with NVMe, without much fanfare. Cost is only ~20% more than SATA.

Re: Modern storage is plenty fast, but the APIs are bad

#36

Post by wtallis »

jeroenhd wrote: post #29

I suppose _modern_ storage is fast, but how many servers are running on storage this modern? None of mine are and my work dev machine is still rocking a SATA 2.5" SSD. We're probably still a few years off from being able to switch to this fast I/O yet. With the new game consoles switching over to PCIe SSDs I expect the price of NVMe drives to drop over the next few years until they're cheap enough that the majority o…

> I expect the price of NVMe drives to drop over the next few years until they're cheap enough that the majority of computers are running NVMe drives.

Price no longer has anything to do with it. PC OEMs are simply not shipping SATA SSDs any more, and major drive vendors have started to discontinue their client (OEM) SATA SSD product lines. We're just waiting for the SATA-based PC install base to be retired.

Re: Modern storage is plenty fast, but the APIs are bad

#37

Post by Ericson2314 »

From the author's previous piece: https://www.scylladb.com/2020/05/05/how-io_uring-and-ebpf-wi...

> Our CTO, Avi Kivity, made the case for async at the Core C++ 2019 event. The bottom line is this; in modern multicore, multi-CPU devices, the CPU itself is now basically a network, the intercommunication between all the CPUs is another network, and calls to disk I/O are effectively another. There are good reasons why network programming is done asynchronously, and you should consider that for your own application development too. > > It fundamentally changes the way Linux applications are to be designed: Instead of a flow of code that issues syscalls when needed, that have to think about whether or not a file is ready, they naturally become an event-loop that constantly add things to a shared buffer, deals with the previous entries that completed, rinse, repeat.

As someone that's been working on FRP related things for a while now, this feels very vindicating. :)

I few like as recently as a few years ago, the systems world was content with it's incremental hacks, but now the gap between the traditional interfaces and hardware realities has become too much, and bigger redesigning is afoot.

Excited for what emerges!

Re: Modern storage is plenty fast, but the APIs are bad

#38

Post by wmf »

_urga wrote: post #14
ivoras wrote: post #2

> ...misconceptions... Yet if you skim through specs of modern NVMe devices you see commodity devices with latencies in the microseconds range and several GB/s of throughput supporting several hundred thousands random IOPS. So where’s the disconnect? Whoa there... let's not compare devices with 20+ GB/s and latencies in nanosecond ranges which translate to half a dozen giga-ops per second (aka RAM) with any kind of f…

The advertised bandwidth for RAM is not actually what you get per-core, which is what you care about in practice. If you want to know the upper bound on your per-core RAM bandwidth: 64 bytes (the size of a cache line) * 10 slots (in a CPU core's LFB or line fill buffer) / 100ns (the typical cost of a cache miss) * 1000000 * 1000 (to convert ns to ms to seconds) = 6400000000 bytes per second = 5.96 GiB per second RAM…

What about prefetching? Tiger Lake gets over 20 GB/s per core. https://www.anandtech.com/show/16084/intel-tiger-lake-review...

Re: Modern storage is plenty fast, but the APIs are bad

#39

Post by sgtnoodle »

_urga wrote: post #14
ivoras wrote: post #2

> ...misconceptions... Yet if you skim through specs of modern NVMe devices you see commodity devices with latencies in the microseconds range and several GB/s of throughput supporting several hundred thousands random IOPS. So where’s the disconnect? Whoa there... let's not compare devices with 20+ GB/s and latencies in nanosecond ranges which translate to half a dozen giga-ops per second (aka RAM) with any kind of f…

The advertised bandwidth for RAM is not actually what you get per-core, which is what you care about in practice. If you want to know the upper bound on your per-core RAM bandwidth: 64 bytes (the size of a cache line) * 10 slots (in a CPU core's LFB or line fill buffer) / 100ns (the typical cost of a cache miss) * 1000000 * 1000 (to convert ns to ms to seconds) = 6400000000 bytes per second = 5.96 GiB per second RAM…

While I was in the hospital ICU earlier this year, I promised myself I would build a zen 3 desktop when it came out despite my 10 year old desktop still working just fine.

I've since bought all the pieces but the CPU; they are all sold out. So I got a 6 core 3600XT in the interim. I bought fairly high binned RAM and overclocked it to 3600Mhz, and was surprised to cap out at about 36GB/s throughput. Your 6GiB/s per core explanation checks out for me!

Re: Modern storage is plenty fast, but the APIs are bad

#40

Post by wtallis »

gogopuppygogo wrote: post #22
wtallis wrote: post #5

Earlier quoted context omitted.

The article isn't exactly conflating RAM and flash; if it were, the conclusions would be very different. A synchronous blocking IO API is fine if you're working with nanosecond latencies of RAM, or with storage that's as painfully slow and serial as a mechanical hard drive. Flash is special in that its latency is still considerably higher than that of DRAM, but its throughput can get reasonably close once you have mo…

Sustainable read/write speeds are also different than peak on SSD vs RAM.

True, but that applies more to writes than reads. Most real-world workloads do a lot more reads than writes, and what writes they do perform can usually tolerate a lot of buffering in the IO stack to further reduce the overall impact of low write performance on the underlying storage.
Post reply on HN