duncan@helium.siesoft.co.uk (Duncan McEwan) (11/17/89)
chris@mimsy.umd.edu (Chris Torek) writes: >#define blksize(fs, ip, lbn) \ > (((lbn) >= NDADDR || (ip)->i_size >= ((lbn) + 1) << (fs)->fs_bshift) \ > ? (fs)->fs_bsize \ > : (fragroundup(fs, blkoff(fs, (ip)->i_size)))) > ... > >(Thus, files >= 48K (4k/any) or 96K (8K/any) never end in a fragment.) This last statement reminds me of something I have been puzzling over recently. Do the disk addresses kept in the inode and indirect blocks address blocks or fragments? The above seems to indicate blocks, since for the size of a file with indirect blocks (lbn >= NDADDR) to be >= 48K on a 4K/any filesystem each of the NDADDR (12) pointers must address a 4K block. A comment in the "Design and Implementation of 4.3BSD" backs this up. There it says that to ensure files as large as 2^32 can be created with only two levels of indirection, the minimum size of a file system block is 4K. So if as it seems, the pointers do address blocks rather than fragments, how can the file system locate which fragments in a block belong to a the file when the inode only contains a pointer to the block? Answer by mail if the answer is so obvious that there will be many replys to this. I will post the answer if I don't see it here after a reasonable interval. --- Duncan (duncan@siesoft.co.uk, ...!ukc!siesoft!duncan)
chris@mimsy.umd.edu (Chris Torek) (11/23/89)
In article <1727@neon.siesoft.co.uk> duncan@helium.siesoft.co.uk (Duncan McEwan) writes: >.... Do the disk addresses kept in the inode and indirect blocks >address blocks or fragments? The things *in* ip->i_db[i] are in terms of fragments. The values i used to index into ip->i_db[] are in terms of blocks. That is: ip->i_db[howmany(offset, blksize)] is the fragment-wise block number of the disk-block-or-fragment that holds the bytes from floor(offset/blksize)*blksize to ceil(offset/blksize)*blksize-1. More specifically, on an 8k/1k file system, if you want to find the set of 1024-byte disk `blocks' that contain bytes 8192..16383 of a given file, you look at ip->i_db[1]. If this contains the number 2000, those bytes are in the eight consecutive 1024-byte fragments numbered 2000, 2001, 2002, ..., 2007. If, however, the file is only 10240 bytes long, then there are only two such 1024-byte blocks, namely 2000 and 2001. There are various implications here that I leave to the reader. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@cs.umd.edu Path: uunet!mimsy!chris
chris@mimsy.umd.edu (Chris Torek) (11/24/89)
In article I wrote: >The things *in* ip->i_db[i] are in terms of fragments. Aack! They are in terms of DEV_BSIZE (512, on the VAX; 1024 on the Tahoe) byte blocks. >More specifically, on an 8k/1k file system, if you want to find >the set of 1024-byte disk `blocks' that contain bytes 8192..16383 >of a given file, you look at ip->i_db[1]. If this contains the >number 2000, those bytes are in the eight consecutive 1024-byte >fragments numbered 2000, 2001, 2002, ..., 2007. You would see 4000, and use blocks 4000, 4002, 4004, ..., 4014. (Or you could see 2000, and use 2000, 2002, 2004, ..., 2014.) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@cs.umd.edu Path: uunet!mimsy!chris