lkml.org 
[lkml]   [1999]   [Mar]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: breaking the 2Gigabyte limit on 32 bit arch of inode->i_size (off_t vs loff_t)


On Sun, 21 Mar 1999, Andrea Arcangeli wrote:

> On Sat, 20 Mar 1999, Alexander Viro wrote:
>
> >> so the number of blocks we'll be able to address once we'll broke the
> >> i_size limit will be:
> >>
> >> 12 + 256 + 256^2 + 256^3 -> 16843020
> >>
> >> Considering blocksize = 1k we'll be able to address only 16giga according
> >> to me. So I'll add a quad level of indirection. This will give as a view
> >
> > Or we can use 4k blocks and get 256 times more than that. I.e.
> >same 4Tb.
>
> 12 + 1024 + 1024^2 + 1024^3 = 1.074.791.436 -> 4^12 max filesize.

Exactly. 1024^3*4K=4T

> So you think it doesn't worth to have a quad level of indirection to be
> allowed to create a filesystem with 1k of blocksize and to be still able
> to play with files >16giga, right? Having such level of indirection won't
> change the size of the metadata we'll have on disk, but it will allow it
> to be more finegrined on the disk side, saving some good bit of space. But
> maybe if you have a so big fs you don't care losing a mean of some kbyte
> per inode, and probably is better to decrease the complexity of the fs,
> right?

To start with, you are *not* going to have a good life with
anything along the lines of ext2 on such sizes. Think of the time fsck
will take. So I *seriously* doubt that it goes beyond the academical
exercise. Moreover, anything beyond 16G is going to have a pretty complex
internal structure and most likely will prefer to live on a separate
device.


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

\
 
 \ /
  Last update: 2005-03-22 13:50    [from the cache]
©2003-2014 Jasper Spaans. Advertise on this site