> 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. ;-)