4 ms·

I've spent a lot of my career automating datacenter and HPC environments and I disagree with several of these points. * Big distributed storage systems still u

I've spent a lot of my career automating datacenter and HPC environments and I disagree with several of these points. * Big distributed storage systems still use hdd's, usually within a tired system including ssds and nvme. * A good nfs server implementation will beat the pants off all the cloud vendors. It's still highly relevant in physical datacenters. * Mmap is used heavily in a ton of software for good reason. On top of that it's part of the POSIX API. * While block size is one of those things where it usually doesn't matter until it does, just staying bigger blocks is faster is a bit misleading.

crabbone 3y ago
For the record, I work in HPC environment, but originally, my background is in storage. > Big distributed storage systems still use hdd's So what? Did you read what I wrote? I wrote about developing new, not supporting old... > A good nfs server implementation will beat the pants off all the cloud vendors. What are you even talking about? What cloud vendors have to do with this? Did you read what you replied to? > Mmap is used heavily in a ton of software for good reason So what? OP is asking in the context of writing a database / disk I/O. It's a wrong system API to do that. It's intended for applications to "easily" saving their in-memory data. If that's what it's used for, then it's fine. If it's used to implement a filesystem, then the filesystem authors don't understand what they are doing. Also, being part of POSIX or any other standard doesn't warrant a magical resilience to being a bad functionality... just look at the history of UNIX / Linux repeatedly failing to come up with an interface for asynchronous I/O, and sure enough, all these iterations made it into the standard. > just staying bigger blocks is faster is a bit misleading. It's not misleading. For the one paragraph answer, it's perfectly correct. And, no, block size is a very important aspect of any storage system, it's not something that may not matter. --- As an aside: you sound pretentious, and try to pass as knowledgeable by saying things that have a drop of truth, but are mostly fancily dressed nonsense. Just stop. It's embarrassing.

crabbone 3y ago

For the record, I work in HPC environment, but originally, my background is in storage. > Big distributed storage systems still use hdd's So what? Did you read what I wrote? I wrote about developing new, not supporting old... > A good nfs server implementation will beat the pants off all the cloud vendors. What are you even talking about? What cloud vendors have to do with this? Did you read what you replied to? > Mmap is used heavily in a ton of software for good reason So what? OP is asking in the context of writing a database / disk I/O. It's a wrong system API to do that. It's intended for applications to "easily" saving their in-memory data. If that's what it's used for, then it's fine. If it's used to implement a filesystem, then the filesystem authors don't understand what they are doing. Also, being part of POSIX or any other standard doesn't warrant a magical resilience to being a bad functionality... just look at the history of UNIX / Linux repeatedly failing to come up with an interface for asynchronous I/O, and sure enough, all these iterations made it into the standard. > just staying bigger blocks is faster is a bit misleading. It's not misleading. For the one paragraph answer, it's perfectly correct. And, no, block size is a very important aspect of any storage system, it's not something that may not matter. --- As an aside: you sound pretentious, and try to pass as knowledgeable by saying things that have a drop of truth, but are mostly fancily dressed nonsense. Just stop. It's embarrassing.