donn@sdchema.UUCP (03/29/84)
I goofed. The 'di_blocks' field in an inode contains the number of sectors held in both data blocks AND indirect blocks. Kirk Mckusick has straightened me out on this and I thought I owed it to the net to clear up any confusion that my article might have caused. I originally had the right idea, but when I tried fixing 'dump' so that it only used the 'di_blocks' estimate without adding in the indirect blocks, I came up short. After that I just assumed that 'di_blocks' didn't count indirect blocks. After I got Kirk's letter I made an empty filesystem and created a file in it that was one byte over a gigabyte in size, but the only allocated byte was the last one. An 'ls -s' showed that 'di_nblocks' counted two indirect blocks and one data block. But 2050 more tape blocks were needed to dump the filesystem than before... The answer is, of course, that 'dump' fills in unallocated indirect blocks when it puts a file on tape. Without actually searching a file's indirect blocks, then, my estimate comes as close as you can get to the actual number of blocks that will be dumped. The difference will be precisely the amount of space taken up by allocated indirect blocks in files with holes plus the unused TP_BSIZE chunks in the last blocks of those files. So I got the right answer in spite of myself. My apologies to everyone who was misled. Donn Seeley UCSD Chemistry Dept. ucbvax!sdcsvax!sdchema!donn