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

151–160 of 168 posts

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

#151

Post by Spooky23 »

tpurves wrote: post #92
mikepurvis wrote: post #67

Earlier quoted context omitted.

It's a pretty common pattern to have a fleet of big beefy VM hosts all backed by a single giant SAN on a 10gbe switch. This lets you do things like seamlessly migrate a VM from one host to another, or do a high availability thing with multiple synchronized instances and automatic failover (VMWare called this all "vMotion"). In any case, lots of bandwidth to the storage, but also high latency, at least relative to a l…

Why not consider nVME in this case then as cheaper than RAM, slower than RAM, but faster than network storage? I don't know how you handle concurrency btwn VMs or virtualize that storage, but there must be some standard for that?

It depends on what you want to spend your labor dollars on. I run a complex system on HPE storage which is all SSD or NVME and is super fast. You pay, but the vendor mostly takes care of it operationally — I pay for about 20% of a SAN sme, mostly to do maintenance on the storage fabric.

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

#152

Post by scottlamb »

Nice article. This part puzzled me though:

> The operating system reads data in page granularity, meaning it can only read at a minimum 4kB at a time. That means if you need to read read 1kB split in two files, 512 bytes each, you are effectively reading 8kB to serve 1kB, wasting 87% of the data read.

SSDs (whether SATA or NVMe) all read and write whole sectors at a time, right? I'm not sure what the sector size is, but 4 KiB seems like a reasonable guess. So I think you're reading the 8 KiB no matter what; it may just be a question of what layer you drop it at (right when it gets to the kernel or not). Also, doesn't direct IO require sector size-aligned operations?

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

#153

Post by [deleted] »

scottlamb wrote: post #152

Nice article. This part puzzled me though: > The operating system reads data in page granularity, meaning it can only read at a minimum 4kB at a time. That means if you need to read read 1kB split in two files, 512 bytes each, you are effectively reading 8kB to serve 1kB, wasting 87% of the data read. SSDs (whether SATA or NVMe) all read and write whole sectors at a time, right? I'm not sure what the sector size is,…

[deleted]

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

#155

Post by AtlasBarfed »

AWS EBS gp2 is far from an NVMe drive.

Everyone architects for AWS these days. So the limitations of EBS still dominate I/O: limited IOPS, limited bandwidth.

Yes there are ephemerals. Which are basically little more than ramdisks/caches to actual AWS design.

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

#156

Post by int_19h »

wtallis wrote: post #140
p1necone wrote: post #118

Earlier quoted context omitted.

Drive price doesn't scale linearly with capacity, you can save a fair bit of money sticking with multiple smaller capacity drives vs one big one.

Drive price per GB doesn't even scale monotonically with capacity. Right now, the best price per GB is usually on 1TB or 2TB models. And if you need more than two such devices with SSD performance, you're far outside the bounds of consumer computing and into workstation territory.

It depends on what you mean by "consumer computing", really. The single largest app using up my disk space is Steam, and if I only had a single 1 Tb SSD, it'd be full by now.

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

#158

Post by vbezhenar »

Miraste wrote: post #81
arka2147483647 wrote: post #55

Earlier quoted context omitted.

I read that as that it was what he had at hand when running the tests. Also, if the speed and features are available as professional grade devices today, it will be available everywhere in a few years.

Optane has been commercially available for five years already and it's not used in any device I'm aware of. Assuming it will find broad adoption at this point seems like a bad bet.

Optane in consumer devices is in a weird place. Write durability does not matter, SSD manufacturers reduce rewrite count with every new generation in the name of the cheaper prices and users are happy to accept that downgrade (see Samsung 980 Pro vs Samsung 970 Pro for a recent occasion). Speed matters to some extent. Many users don't observe performance improvements in their typical tasks when upgrading from SATA SSD to M.2 PCI-E SSD, so they definitely wouldn't notice speed improvement upgrading from M.2 to Optane. And yet Optane's cost is not cheap.

I just don't see place for Optane in any user devices. It's either servers, but it's not obvious choice there or tiny market for benchmark users. May be someone like Apple with its vertical integration could exploit it extreme speed to achieve something awesome, but I doubt it, they don't like to depend on a single supplier.

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

#159

Post by mtgx »

Miraste wrote: post #81
arka2147483647 wrote: post #55

Earlier quoted context omitted.

I read that as that it was what he had at hand when running the tests. Also, if the speed and features are available as professional grade devices today, it will be available everywhere in a few years.

Optane has been commercially available for five years already and it's not used in any device I'm aware of. Assuming it will find broad adoption at this point seems like a bad bet.

Yeah, I'd say ReRAM SSDs will have a better chance of becoming mainstream, and with better performance/$, too.

I think Sony is planning on commercializing it next year. Probably Western Digital, too.

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

#160

Post by amelius »

pixl97 wrote: post #136
amelius wrote: post #123

Earlier quoted context omitted.

Permissions (and ownership info) can be useful even if you have complete access to a filesystem. By the way, assume you have root permission. How would you replace a single file in a random tar-file, without changing any of the permissions/userids/groupids inside the tar-file? You can't untar it because the users inside the tar file don't correspond with the ones on your system. So, you'll have to use special tools,…

Don't the files on disk just keep the current uid/gid anyway. You'd change one file and zip it back up. Seen plenty of files with just a number instead of an owner in the past.

There are two problems with this. 1. Tar also stores user and group names, which you see when you use the "v" and "t" options. 2. If you try this as non-root user, you run into permission problems.
Post reply on HN