>Are there any deeper reasons,
>why
>a) inode->i_blksize is set to PAGESIZE eg. 4096 independent of the actual
>block size of the file system?
Well, why not? The field tells what is a good chunk size to read or write
for maximum performance. If the I/O is done in PAGESIZE cache page units,
then that's the best number to use.
I suppose in the very first unix filesystems, the field may have meant
filesystem block size, which was identical to the highest performing
read/write size, and that may account for its name.
>b) the number of blocks is counted in 512 Bytes and not in the actual
blocksize
>of the filesystem?
I can't see how the number of actual blocks would be helpful, especially
since as described above, we don't even know how big they are. We don't
even know that they're fixed size or that a concept of a block even exists.
>(is this for historical reasons??)
That would be my guess. Though I can't think of any particular programs
that would measure a file by multiplying this number by 512.
In any case, the inode fields are defined as they are because they
implement a standard stat() interface that includes these same numbers.
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
