Re: Filesize limitation

Daniel G. Linder (dlinder@zeus.webcentric.net)
Fri, 7 Nov 1997 11:50:21 -0600 (CST)

kris@koehntopp.de (Kristian Koehntopp) wrote:
>In netuse.lists.linux-kernel you write:
>>How difficult would it be to upgrade this to a ext3 filesystem with
>>32 bits reserved for gid and uid, and 64 bits for length and block count?:
>It is possible, but it would make the on-disk inode slightly
>larger than 128 byte, so there is about 100 unused bytes per
>inode. These bytes could be used otherwise (more direct blocks,
>for example), which would be a very traditional and evolutionary
>approach to the problem of large files. Such an ext3 would
>relate to ext2 as xiafs relates to minixfs: It simply extends
>the existing structures, but does nothing to improve the
>infrastructure.

[snip -- discussion of "radical" filesystem ideas by SGI, Microsoft,
reiserfs, and others.]

>Kristian

I don't have nearly as much knowledge on this as I would like, but my
gut feeling is if we are going to re-work/create a filesystem to allow 64
bit lengths, counts, id's, etc., why stop at 64 bits? A quick bit of math
shows that 128 bit would "really" hold us for a while. (2^128 "atoms" one
Angstrom sized would be a cube over 650meters per side!) For the next two
years or so, I forsee that the vast majority of Linux users will be able
to live with the current ext2 filesystem. My dream would be that for the
year 2000, we could introduce to the world a stable, reliable, tolerant
128-bit based filesystem.

I have not had enough time to read through Hans Reisers' white paper on
his ReiserFS (http://idiom.com/~beverly/reiserfs.html) to know if it is
extensible to large physical drives, if it can stripe/RAID drives, etc.

Dan

--
Daniel Linder W:(402) 393-3997 C:(402) 490-1673 P:(402) 579-1615
National TechTeam / WebCentric
www.webcentric.net / www.techteam.com
'69 Corvette  /  '95 Grand Prix GTP