>> >a) inode->i_blksize is set to PAGESIZE eg. 4096 independent of the
>> > actual block size of the file system?
>
>>If the I/O is done in PAGESIZE(-size) cache
>> page units, then that's the best number to use.
>
>But we already know that from PAGE_SIZE, this seems like a complete
>waste.
OK, but who's "we"? Individual filesystem drivers (some of them, that is)
know that the optimum read/write size is PAGESIZE. But does the FS layer?
And if the FS layer doesn't, the user space program certainly can't. The
ext2 driver sets i_blksize to PAGESIZE, but another driver might set it to
something else. FS blindly passes i_blksize up to user space (via stat()).
>> In any case, the inode fields are defined as they are because they
>> implement a standard stat() interface that includes these same
>> numbers.
>
>We can fix things up in cp_old/new_stat if we want.
Just as long as all the information is in the inode. Which I think is what
the issue is.
I'm more confused than ever about the i_blocks (filesize divided by 512)
field. I note that in both the inode and the stat() result, the filesize
in bytes exists, and presumably always has. So why would anyone ever want
to know separately how many 512 byte units of data are in the file? FS
code appears to explicitly allow for a filesystem driver to denominate
i_blocks in other units, but any other unit would appear to break the stat
() interface.
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
