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

-- Terry
[EMAIL PROTECTED] mailing list
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to