marc@petrus.UUCP (Marc Pucci) (11/25/85)
> > it's partly a function of hardware as well. tradition has it that all disk > > blocks are 512 bytes. this is fine on a smaller machine where there was > > only 64K to work with, the CPU and memory are slow, and so was the disk. > > you can make block sizes bigger, but still you have to live with hardware > > that doesn't understand it. > > On System V, the physical block sizes are 1K. I think the physical block-size is still assumed to be 512 bytes. That is, the assumed sector size of disks is 512. When I did a port of system V to a system with physical 1024 byte disk sectors, I had problems with programs like ncheck, fsck, etc. with raw disk partitions. They all assumed they could seek to 512 (super-block offset) and read the superblock. Unfortunatly, the raw disk interface insists on only sector aligned, multiple-of-sector-size reads. Marc Pucci, Bell Communications Research, Morristown, NJ
mark@cbosgd.UUCP (Mark Horton) (11/26/85)
> > it's partly a function of hardware as well. tradition has it that all disk > > blocks are 512 bytes. this is fine on a smaller machine where there was > > only 64K to work with, the CPU and memory are slow, and so was the disk. > > you can make block sizes bigger, but still you have to live with hardware > > that doesn't understand it. > > On System V, the physical block sizes are 1K. Unfortunately, in System V, the number 512 is thoroughly embedded into nearly all levels of the system. At the physical level, disk sectors are assumed to be 512 bytes. (This is true of 4BSD also.) When you do a "du" or an "ls -s", the units reported to the user are "blocks", which everyone knows are 512 bytes each. In fact, I often ask someone how much disk space something takes up, and they tell me how many "blocks" it takes up, assuming I know that "blocks" are 512 bytes. Berkeley has attempted to change the units that people think in to "K", e.g. 1024 bytes. While I've changed my thinking to K and Megabytes, I still have to translate from the old system because of all the people out there that have 512 stamped onto their brains. It's like translating between the traditional and metric systems - if we'd all go cold turkey at once it wouldn't be any big deal. The filesystems do work in bigger units, and this produces significant speedups. System V typically does disk transfers in units of 1K (this means that when it wants a disk block, it transfers two 512 byte sectors at once.) 4.2BSD is similar, although it does 4K or 8K transfers by doing 8 or 16 sectors at once. (There are exceptions, of course, some systems still use 512, others use 4K, etc.)
avolio@decuac.UUCP (Frederick M. Avolio) (11/27/85)
In article <1638@cbosgd.UUCP>, mark@cbosgd.UUCP (Mark Horton) writes: > Unfortunately, in System V, the number 512 is thoroughly embedded into > nearly all levels of the system. ... > Berkeley has attempted to change the units that people think in to "K", e.g. > 1024 bytes. ... > The filesystems do work in bigger units, and this produces significant > speedups. System V typically does disk transfers in units of 1K ... > 4.2BSD is similar, although it does 4K or 8K transfers ... But there are still hard-coded "blocksizes" independant of what one defines a file system block size at newfs time in 4.2BSD. If one sets up quotas, the format is to give disk use restrictions in "blocks." But what is really meant is "1024 bytes" since even if my block size is 8192, edquota still wants number of blocks assuming a 1024 byte block. -- Fred @ DEC Ultrix Applications Center {decvax,seismo,cbosgd}!decuac!avolio