David Gilbert wrote:
> >>>>> "Poul-Henning" == Poul-Henning Kamp <[EMAIL PROTECTED]> writes:
> Poul-Henning> I am not sure I would advocate 64k blocks yet.
> Poul-Henning> I tend to stick with 32k block, 4k fragment myself.
> That reminds me... has anyone thought of designing the system to have
> more than 8 frags per block? Increasingly, for large file
> performance, we're pushing up the block size dramatically. This is
> with the assumption that large disks will contain large files.
My assumptions on the previous two statements by Poul are:
1) You cannot trust that a short will be treated as an
unsigned 16 bit value in all cases, so values that
are between 32768 and 65535 may be treated incorrectly.
2) A fully populate block bitmap byte, which means a divide
by 8, is necessary to avoid potential division errors.
In other words, he's afraid that the sign bit and/or the block
size bitmap used by frags may be treated incorrectly.
I have to agree with both those observations. A number of people
have, historically, reported issues with a divisor other than 8,
and the worry about the sign bit is common sense, given the many
historical issues faced by other OS's when it comes to 64K block
[EMAIL PROTECTED] mailing list
To unsubscribe, send any mail to "[EMAIL PROTECTED]"