On Wed, Sep 17, 2008 at 6:16 PM, Sunil <infinite.questions@xxxxxxxxx> wrote: > Hi, > > For a disk file-system, if the on disk layout is static, like EXT2 or UFS, > what parameter decides the maximum size of file-system or file on it ? I > would guess the 'size of inode entry used to store the block number' will > decide the maximum number of blocks it can address. This together with 'size > of block' should decide these limits. Yes, pretty much it depends on the number of number of blocks that you can address and the block size. Though it also depends on the way you store or refer your block numbers. For example in case of EXT2 it will be blocknumbers*blocksize......but since newer filesystems EXT4 also have the concept of extents it is also possible to have much larger sizes with 32 bit block numbers. > > Another thing is, is it a usually followed that this 'inode entry used to > store the block number' is usually long, which maps to word size of > underlying architecture[correct here if needed]. On 32bit architecture, > where word size and hence long is 32bit, if we use long long data type for > this, for each comparison of block numbers or in-memory processing of it, > one would need to read two words each time. Does it really help to improve > performance ? Or it doesnt affect and block number could be long long ? Its not only about increasing the block numbers from 32 bit to 64 bit. Apart from two reads if you have a very large filesystem things like fsck will take a long time to complete (that is why EXT4 uses only 48 bits, IIRC) so you need to consider them too. With 64 bits the number of entries that you can store in direct block pointers will also be less. hope that helps.... Thanks - Manish Katiyar > > Thanks. > > - > Sunil. > -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
