lkml.org 
[lkml]   [2002]   [Aug]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: BIG files & file systems
On Aug 06, 2002  03:24 -0400, Albert D. Cahalan wrote:
> Andreas Dilger writes:
> > Having 16kB block size would allow a maximum of 64TB for a single
> > filesystem. The per-file limit would be over 256TB.
>
> Um, yeah, 64 TB of data with 192 TB of holes!
> I really don't think you should count a file
> that won't fit on your filesystem.

Well, no worse than the original posting which had reiserfs supporting
something-EB files and 16TB filesystems. Don't think I didn't consider
this at the time of posting.

> > In reality, we will probably implement extent-based allocation for
> > ext3 when we start getting into filesystems that large, which has been
> > discussed among the ext2/ext3 developers already.
>
> It's nice to have a simple filesystem. If you turn ext2/ext3
> into an XFS/JFS competitor, then what is left? Just minix fs?

Note that I said ext3 in the above sentence, and not ext2. I'm not in
favour of adding all of the high-end features (htree, extents, etc) into
ext2 at all. It makes absolutely no sense to have a multi-TB filesystem
running ext2, and then the fsck time takes a day. It is desirable to
put some minimum support into ext2 for newer features when it makes
sense and does not complicate the code, but not for everything.

Cheers, Andreas
--
Andreas Dilger
http://www-mddsp.enel.ucalgary.ca/People/adilger/
http://sourceforge.net/projects/ext2resize/

-
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/

\
 
 \ /
  Last update: 2005-03-22 13:27    [W:1.258 / U:0.012 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site