From: Rob Landley <rob@landley.net>
Organization: Boundaries Unlimited
To: Bernd Eckenfels <ecki@lina.inka.de>
Subject: Re: what is our answer to ZFS?
Date: Tue, 22 Nov 2005 01:15:17 -0600
User-Agent: KMail/1.8
Cc: linux-kernel@vger.kernel.org
References: <E1EeLp5-0002fZ-00@calista.inka.de>
In-Reply-To: <E1EeLp5-0002fZ-00@calista.inka.de>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200511220115.17450.rob@landley.net>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1155
Lines: 27

On Monday 21 November 2005 18:15, Bernd Eckenfels wrote:
> In article <200511211252.04217.rob@landley.net> you wrote:
> > 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.
>
> The prolem is not about file size. It is about for example unique inode
> numbers. If you have a file system which spans multiple volumnes and maybe
> nodes, you need more unqiue methods of addressing the files and blocks.

18 quintillion inodes are enough to give every ipv4 address on the internet 4 
billion unique inodes.  I take it this is not enough space for Sun to work 
out a reasonable allocation strategy in?

Rob


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/