From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Michael Tokarev <mjt@tls.msk.ru>
Cc: Jens Axboe <jens.axboe@oracle.com>,
Kay Sievers <kay.sievers@vrfy.org>,
Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>,
linux-kernel@vger.kernel.org, linux-ide@vger.kernel.org,
Alan Cox <alan@lxorguk.ukuu.org.uk>
Subject: Re: [PATCH] block: export SSD/non-rotational queue flag through sysfs
Date: Wed, 07 Jan 2009 09:34:33 -0600 [thread overview]
Message-ID: <1231342473.3282.19.camel@localhost.localdomain> (raw)
In-Reply-To: <4964866D.8010503@msgid.tls.msk.ru>
On Wed, 2009-01-07 at 13:39 +0300, Michael Tokarev wrote:
> Jens Axboe wrote:
> > On Mon, Jan 05 2009, Kay Sievers wrote:
> >> On Mon, Jan 5, 2009 at 19:54, Jens Axboe <jens.axboe@oracle.com> wrote:
> >>> On Mon, Jan 05 2009, Bartlomiej Zolnierkiewicz wrote:
> >>>> +static struct queue_sysfs_entry queue_nonrot_entry = {
> >>>> + .attr = {.name = "nonrot", .mode = S_IRUGO | S_IWUSR },
> >>>> + .show = queue_nonrot_show,
> >>>> + .store = queue_nonrot_store,
> >>>> +};
> >>>> +
> >>> Lets please use a better name for export reasons, non-rotational is a
> >>> lot better. Nobody will know what nonrot means :-)
> >> What's that negation good for? Can't we just have "rotational", like
> >> we have "removable" and not "non-removable"? :)
> >
> > Non-rotational is the term typically used, since rotational is the norm
> > (still). So I think the negation actually makes sense in this case :-)
>
> You used the word "still" yourself. I mean, in 5 years SSD will be more
> common than rotational media, and "the norm" will be !rotational..
> So let's name them correctly and uniformly from the beginning.. ;)
I'm afraid that's pretty much marketing coolaid. Rotational storage
will dominate for the forseeable future: just do a simple back of the
envelope calculation:
* Total shipped spinning storage in 2008: 128EB (Gartner figures)
* If all the chip FABs in all the world were turned solely to
flash production, they'd be able to ship about 16EB per year (or
about 13% of the total 2008 consumption [estimate from Steve
Hetzler, IBM]), assuming any given FAB can produce about 0.5EB
per year).
* Then factor in that storage requirements are growing
exponentially (the 2009 estimated requirement is 400EB).
* Given that it costs ~$3-7bn for one fab plant and that we're in
an economic depression, no-one is making the necessary trillion
dollar capital investment to even make Flash be a significant
fraction of the current storage market ... it's not even clear
that it will be able to break the 1% barrier, let alone the 10%
one.
That's not to say flash isn't important, it is; it's just to remind
everyone that storage subsystems will be focused on rotating media. Any
flash features we add have to make sure they don't impact our rotating
performance.
Sorry, now we can go back to regularly scheduled programming. This
isn't the first "everything will be flash and we should be planning for
it" type statement, but I thought a little reality injection would be
appropriate at this juncture.
James
next prev parent reply other threads:[~2009-01-07 15:34 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-05 18:52 [PATCH] block: export SSD/non-rotational queue flag through sysfs Bartlomiej Zolnierkiewicz
2009-01-05 18:54 ` Jens Axboe
2009-01-05 19:02 ` Bartlomiej Zolnierkiewicz
2009-01-05 19:08 ` James Bottomley
2009-01-05 19:10 ` Jens Axboe
2009-01-05 19:08 ` Jens Axboe
2009-01-05 21:47 ` Kay Sievers
2009-01-06 7:35 ` Jens Axboe
2009-01-07 10:39 ` Michael Tokarev
2009-01-07 11:19 ` Jens Axboe
2009-01-07 15:34 ` James Bottomley [this message]
2009-01-15 5:37 ` Tejun Heo
2009-01-15 15:07 ` Greg Freemyer
2009-01-15 15:46 ` Tejun Heo
2009-01-15 16:06 ` James Bottomley
2009-01-15 18:55 ` Grant Grundler
2009-01-15 19:00 ` James Bottomley
2009-01-15 22:45 ` Grant Grundler
2009-01-15 23:17 ` James Bottomley
2009-01-15 23:50 ` Hugh Dickins
2009-01-15 23:57 ` Michael Tokarev
2009-01-16 0:36 ` James Bottomley
2009-01-16 3:52 ` Dongjun Shin
2009-01-16 6:48 ` Jens Axboe
2009-01-16 6:48 ` Jens Axboe
2009-02-03 12:32 ` Pierre Ossman
2009-01-16 6:43 ` Jens Axboe
2009-01-05 18:58 ` Alan Cox
[not found] <fa.+H1UnEqOmFht/vMPmVy8ellbQi0@ifi.uio.no>
[not found] ` <fa.RLz5WOGorLui5GRkc963Ww1kXqg@ifi.uio.no>
[not found] ` <fa.x4ejZ7Kj7ZZRu88Sond1Cap6XxY@ifi.uio.no>
2009-01-05 22:18 ` Sitsofe Wheeler
2009-01-06 1:25 ` Stefan Richter
2009-01-06 19:46 ` Hugh Dickins
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=1231342473.3282.19.camel@localhost.localdomain \
--to=james.bottomley@hansenpartnership.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=bzolnier@gmail.com \
--cc=jens.axboe@oracle.com \
--cc=kay.sievers@vrfy.org \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mjt@tls.msk.ru \
/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