:sure your amount of metadata that needs checking is reasonably low.
:
:> Also, it seems like 64 bit processors will be in use before 1 TB
:> filesystems are common. Won't the filesystem need to be 64-bitted for
:> that?
:
:I would guess. Matt Dillon commented on this already, though, and is much
:better suited to having an opinion about it.
:
:... Joe
:
:-------------------------------------------------------------------------------
:Joe Greco - Systems Administrator [EMAIL PROTECTED]
:Solaria Public Access UNIX - Milwaukee, WI 414/342-4847
Personally I think going to 64 bit block numbers is overkill. 32 bits
is plenty (for the next few decades) and, generally, people running
filesystems that large tend to be in the 'fewer larger files' category
rather then the 'billions of tiny files' category, so using a large
block size is reasonable. At the moment the filesystem block size is
the kernel's minimum disk I/O (at least when accessing portions backed
by full blocks), but it is far more likely that we change the kernel
to do less then full block reads then it is that we bump up the block
number to 64 bits.
Given a kernel modified to not have to read full blocks, the filesystem
block size becomes more of a 'reservation size' and in multi-terrabyte
filesystems it would not be unreasonable to make this something really
big, like a megabyte (a fragment would then be 128K). With a blocksize
of a megabyte filesystems up to 2048 TB would be possible with 31 bit
block numbers.
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
