From: Pavel Machek <pavel@ucw.cz>
To: Rob Landley <rob@landley.net>
Cc: Tarkan Erimer <tarkane@gmail.com>,
linux-kernel@vger.kernel.org, Diego Calleja <diegocg@gmail.com>
Subject: Re: what is our answer to ZFS?
Date: Tue, 22 Nov 2005 01:45:31 +0100 [thread overview]
Message-ID: <20051122004531.GA15189@elf.ucw.cz> (raw)
In-Reply-To: <200511211252.04217.rob@landley.net>
Hi!
> > 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?
Actually, if you are storing information in single protons, I'd say
you _need_ checksumming :-).
[I actually agree with Sun here, not trusting disk is good idea. At
least you know kernel panic/oops/etc can't be caused by bit corruption on
the disk.]
Pavel
--
Thanks, Sharp!
next prev parent reply other threads:[~2005-11-22 1:13 UTC|newest]
Thread overview: 74+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-21 9:28 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
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 [this message]
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
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=20051122004531.GA15189@elf.ucw.cz \
--to=pavel@ucw.cz \
--cc=diegocg@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rob@landley.net \
--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
all inboxes | Powered by JetHome®