From mboxrd@z Thu Jan 1 00:00:00 1970 To: 9fans@cse.psu.edu From: "Douglas A. Gwyn" Message-ID: <3F09EDB7.626FE4F5@null.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <3F05D809.7030707@null.net>, <0ecb9b15ba9f3534a79e8cc3e4f4cc2c@mightycheese.com> Subject: Re: [9fans] Rstat needs three size fields? Date: Tue, 8 Jul 2003 08:32:01 +0000 Topicbox-Message-UUID: edea54d6-eacb-11e9-9e20-41e7f4b1d025 "rob pike, esq." wrote: > >> 65536 is not a very big number in modern i/o systems. > > Actally neither is 2^32. > sometimes you become boyd-like in your contrarianism. > 2^32 is a huge block size, even today, while 2^16 is not. Perhaps I'm getting tired of engineers always tweaking size fields up by a small amount every time they become too small. If you've had to deal with large IDE drives on BIOSes more than a couple of years old you know what I mean. Ever-increasing-size FAT filesystem formats are another example. Utility software that is even slightly old keeps turning out to be unable to cope with new developments, due mainly to inadequate bits in existing formats. Why should there be such a drain on developer resources to continually adapt to changing formats when we could do it right for once and for all? My rule of thumb used to be that whatever the biggest size you can imagine for some object, allocate twice as many bits to hold its size as seem sufficient. But even that approach doesn't survive for the decades that ought to be attainable for things like disk descriptors.