From: Rob Landley <rob@landley.net>
To: Tarkan Erimer <tarkane@gmail.com>
Cc: linux-kernel@vger.kernel.org, Diego Calleja <diegocg@gmail.com>
Subject: Re: what is our answer to ZFS?
Date: Mon, 21 Nov 2005 12:52:04 -0600 [thread overview]
Message-ID: <200511211252.04217.rob@landley.net> (raw)
In-Reply-To: <9611fa230511210619l208b10a8w77aedaa249345448@mail.gmail.com>
On Monday 21 November 2005 08:19, Tarkan Erimer wrote:
> On 11/21/05, Diego Calleja <diegocg@gmail.com> wrote:
> If It happenned, Sun or someone has port it to linux.
> We will need some VFS changes to handle 128 bit FS as "Jörn ENGEL"
> mentionned previous mail in this thread. Is there any plan or action
> to make VFS handle 128 bit File Sytems like ZFS or future 128 bit
> File Systems ? Any VFS people reply to this, please?
I believe that on 64 bit platforms, Linux has a 64 bit clean VFS. Python says
2**64 is 18446744073709551616, and that's roughly:
18,446,744,073,709,551,616 bytes
18,446,744,073,709 megs
18,446,744,073 gigs
18,446,744 terabytes
18,446 ... what are those, petabytes?
18 Really big lumps of data we won't be using for a while yet.
And that's just 64 bits. Keep in mind it took us around fifty years to burn
through the _first_ thirty two (which makes sense, since Moore's Law says we
need 1 more bit every 18 months). We may go through it faster than we went
through the first 32 bits, but it'll last us a couple decades at least.
Now I'm not saying we won't exhaust 64 bits eventually. Back to chemistry, it
takes 6.02*10^23 protons to weigh 1 gram, and that's just about 2^79, so it's
feasible that someday we might be able to store more than 64 bits of data per
gram, let alone in big room-sized clusters. But it's not going to be for
years and years, and that's a design problem for Sun.
Sun is proposing it can predict what storage layout will be efficient for as
yet unheard of quantities of data, with unknown access patterns, at least a
couple decades from now. It's also proposing that data compression and
checksumming are the filesystem's job. Hands up anybody who spots
conflicting trends here already? Who thinks the 128 bit requirement came
from marketing rather than the engineers?
If you're worried about being able to access your data 2 or 3 decades from
now, you should _not_ be worried about choice of filesystem. You should be
worried about making it _independent_ of what filesystem it's on. For
example, none of the current journaling filesystems in Linux were available
20 years ago, because fsck didn't emerge as a bottleneck until filesystem
sizes got really big.
Rob
next prev parent reply other threads:[~2005-11-21 18:52 UTC|newest]
Thread overview: 74+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-21 9:28 what is our answer to ZFS? Alfred Brons
2005-11-21 9:44 ` Paulo Jorge Matos
2005-11-21 9:59 ` Alfred Brons
2005-11-21 10:08 ` Bernd Petrovitsch
2005-11-21 10:16 ` Andreas Happe
2005-11-21 11:30 ` Anton Altaparmakov
2005-11-21 10:19 ` Jörn Engel
2005-11-21 11:46 ` Matthias Andree
2005-11-21 12:07 ` Kasper Sandberg
2005-11-21 13:18 ` Matthias Andree
2005-11-21 14:18 ` Kasper Sandberg
2005-11-21 14:41 ` Matthias Andree
2005-11-21 15:08 ` Kasper Sandberg
2005-11-22 8:52 ` Matthias Andree
2005-11-21 22:41 ` Bill Davidsen
2005-11-21 20:48 ` jdow
2005-11-22 11:17 ` Jörn Engel
2005-11-21 11:59 ` Diego Calleja
2005-11-22 7:51 ` Christoph Hellwig
2005-11-22 10:28 ` Jörn Engel
2005-11-22 14:50 ` Theodore Ts'o
2005-11-22 15:25 ` Jan Harkes
2005-11-22 16:17 ` Chris Adams
2005-11-22 16:55 ` Anton Altaparmakov
2005-11-22 17:18 ` Theodore Ts'o
2005-11-22 19:25 ` Anton Altaparmakov
2005-11-22 19:52 ` Theodore Ts'o
2005-11-22 20:00 ` Anton Altaparmakov
2005-11-22 23:02 ` Theodore Ts'o
2005-11-22 21:14 ` Bill Davidsen
2005-11-22 21:06 ` Bill Davidsen
2005-11-22 20:19 ` Alan Cox
2005-11-22 19:56 ` Chris Adams
2005-11-22 21:19 ` Bill Davidsen
2005-11-23 19:20 ` Generation numbers in stat was Re: what is slashdot's " Andi Kleen
2005-11-24 5:15 ` Chris Adams
2005-11-24 8:47 ` Andi Kleen
2005-11-22 16:28 ` what is our " Theodore Ts'o
2005-11-22 17:37 ` Jan Harkes
2005-11-22 16:36 ` Jeff V. Merkey
2005-11-28 12:53 ` Lars Marowsky-Bree
2005-11-29 5:04 ` Theodore Ts'o
2005-11-29 5:57 ` Willy Tarreau
2005-11-29 14:42 ` John Stoffel
2005-11-29 13:58 ` Andi Kleen
2005-11-29 16:03 ` Chris Adams
2005-11-21 11:45 ` Diego Calleja
2005-11-21 14:19 ` Tarkan Erimer
2005-11-21 18:52 ` Rob Landley [this message]
2005-11-21 19:28 ` Diego Calleja
2005-11-21 20:02 ` Bernd Petrovitsch
2005-11-22 5:42 ` Rob Landley
2005-11-22 9:25 ` Matthias Andree
2005-11-21 23:05 ` Bill Davidsen
2005-11-22 0:15 ` Bernd Eckenfels
2005-11-21 22:59 ` Jeff V. Merkey
2005-11-22 7:45 ` Christoph Hellwig
2005-11-22 9:19 ` Jeff V. Merkey
2005-11-22 16:00 ` Bill Davidsen
2005-11-22 16:09 ` Jeff V. Merkey
2005-11-22 20:16 ` Bill Davidsen
2005-11-22 16:14 ` Randy.Dunlap
2005-11-22 16:38 ` Steve Flynn
2005-11-22 7:15 ` Rob Landley
2005-11-22 8:16 ` Bernd Eckenfels
2005-11-22 0:45 ` Pavel Machek
2005-11-22 6:34 ` Rob Landley
2005-11-22 19:05 ` Pavel Machek
2005-11-22 9:20 ` Matthias Andree
2005-11-22 10:00 ` Tarkan Erimer
2005-11-22 15:46 ` Jan Dittmer
2005-11-22 16:27 ` Bill Davidsen
2005-11-21 18:17 ` Rob Landley
-- strict thread matches above, loose matches on Subject: below --
2005-11-24 1:52 art
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=200511211252.04217.rob@landley.net \
--to=rob@landley.net \
--cc=diegocg@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=tarkane@gmail.com \
/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