Subject: Re: type-length-value chains for FFS (was large Inodes)
To: Bill Studenmund <firstname.lastname@example.org>
From: John F. Woods <email@example.com>
Date: 03/24/1999 10:43:11
> Yes, I mis-remembered. There is a flag u_int32_t, and 28 BYTES of data, or
> 7 u_int32_t's. Added to the 2 spare u_int32_t's we have now, I think we
> have enough space. We'd need 3 for Y2038, and one for acl's.
OK, so whoever decides to lay claim to the 5th remaining u_int32_t gets to
design the NetBSD Resource Manager. Sounds fair to me. :-)
> Growing the fs to support more than 2^32 blocks (files > 2 Peta bytes or
Isn't it 2 terabytes? That's actually an achievable storage size (for a
RAID system, anyway), if you've got the money.
> so) would require a fair bit of hackery. If we kept NDADDR and NIADDR the
> same, we'd need 15 extra int32_t's. Oh, 16, as we also would want to grow
> the number of blocks in the file. :-) 17 if we have a block address for
> acl's (no need to grow if acl's are kept in a seperate inode).
If you want to be really picky, you only need 3 extra bytes per block pointer,
since the file sizes are still constrained to a mere 64 bits. ;-)