9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: Aleksandar Kuktin <ak@triklod.rs>
To: 9fans@9fans.net
Subject: Re: [9fans] Article: Modern storage is plenty fast. It is the APIs that are bad.
Date: Thu, 10 Dec 2020 17:31:32 +0100	[thread overview]
Message-ID: <20201210173132.7a50c3a9@tannaz.my.domain> (raw)
In-Reply-To: <CAOomyf8AaPXyYnemVXV01r_WUpO1yWw3t3qYrL9ABSNDn6ki+Q@mail.gmail.com>

On Thu, 10 Dec 2020 08:38:14 -0500
Robert Sherwood <robert.sherwood@gmail.com> wrote:

> This is a very interesting article. I'm not enough of an expert on low
> level device access APIs to judge its accuracy, but I thought some of
> you might find it interesting.
> 
> https://itnext.io/modern-storage-is-plenty-fast-it-is-the-apis-that-are-bad-6a68319fbc1a

I had to view this article in Lynx because Firefox wouldn't display
it, due to all the JavaScript. I think that is a good, apt and
important metaphor for the state of modern IT. xD

On the assumption one actually is in a situation where usage of NVMe
devices make sense apriori, I think the article makes valid points. The
catch is most of us are in situations where rotary disks are just good
enough, so the very use of bus-connected SSD storage is under question.

Illustrations: in terms of personal use of computers, I find that only
the very latest of so-called "AAA video games" are having problems with
my single spindle. YouTube doesn't really depend on the (my) disk. For
some years now, I've been working in a web-business, and speaking in
those terms, if you own the hardware your business runs on, you will
probably be playing an optimization game where cost is sure to be a
pretty serious long term concern (even though I hear that on the West
they shell out enormous money for hardware since optimization experts
cost even more that warehouses of underutilized hardware). I did a
little check on Amazon and can see that per-TiB, rotary disks are still
about half the price of various bus-connected SSDs. That's a headwind.
Does it really make sense to spend thousands of iops on a requirement
that could be removed spending a day or two optimizing the server
application? I'm also not sure what effects RAID will have on the
performance of these disks. And if you happen to be a pleb that
utilizes the cloud, you can kiss your I/O optimizations goodbye since
your disk actually lives on a different floor, maybe even a different
building than your CPU/memory and they are connected through a thin
iSCSI/FibreChannel straw you happen to share with 30 other people.

However, io_uris is a very likable solution. I'm glad I read a bit
about it, even if it isn't really all that revolutionary. Good
solutions rarely are. ;)

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tb7a3e3a90eab83b8-M80d775bf9dd488af3579df16
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

      reply	other threads:[~2020-12-10 16:28 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-10 13:38 Robert Sherwood
2020-12-10 16:31 ` Aleksandar Kuktin [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20201210173132.7a50c3a9@tannaz.my.domain \
    --to=ak@triklod.rs \
    --cc=9fans@9fans.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).