On Monday 04 June 2001 19:02, Bryan Henderson wrote:
> >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.
But we already know that from PAGE_SIZE, this seems like a complete
waste.
> 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.
Counting in 512 byte units was just a mistake. The correct units to
count in are sb->s_blocksize. It's a little tricky to change that now
but it still may happen.
> >(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.
The original NEC floppy disk controllers used 512 byte sectors.
> 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.
--
Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
