> now THIS is the kind of info i like from an Open Source based community. ;o)
thanks :) > by the way, my old Operating Systems book says something about Unix filesystems and >inodes, An inode contains information about where to find a file, like what blocks on the disk it occupies, and also things like its name, and permission bits and access times. The inode (AFAIK) in and of itself is not the limiter on a file's size -- at least in a 32-bit environment, our limiter is the size of 'offset', and if the system can't seek past a certain point because the value can't exceed 4G, then that is the limiter of a file's size. Of course, a filesystem design would specify the format of the inodes, and how many blocks there could be, which would in turn limit a file's size, since you can't have more than one inode describing a file -- at least you can't have a file that partly belongs to one inode and finishes with another. In ext2 at least, an inode has space for 14 (1k) blocks, and any file bigger than that has allocated to it a secondary block of pointers to blocks (indirect blocks). That basically lets you specify a megabyte's worth (give or take a few K) of blocks, assuming a 4K indirect block (i.e., 1024 32-bit unsigned block numbers), which I think is right. Anything bigger than that requires a double indirect scheme, which provides another block which specifies a bunch of pointers to (indirect) blocks. I imagine this all scales up to the maximum file size, as I would think that it would be a poor design if it shortchanged in this area. > Damian
Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
