Date: Fri, 05 Sep 2003 22:03:39 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: David Gilbert <dgilbert@dclg.ca> Cc: freebsd-questions@freebsd.org Subject: Re: 20TB Storage System Message-ID: <3F596AAB.843C86F5@mindspring.com> References: <3F5647F3.5080502@he.iki.fi> <16216.36410.889440.499438@canoe.velocet.net>
next in thread | previous in thread | raw e-mail | index | archive | help
David Gilbert wrote: > >>>>> "Poul-Henning" == Poul-Henning Kamp <phk@phk.freebsd.dk> 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 sizes. -- Terry
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3F596AAB.843C86F5>