On Mon, 2006-11-06 at 18:26 -0600, Steve French wrote:
> I assumed that the original intent of the "inode diet patch" was to
> remove fields in the inode,
> which most filesystems can get out of the superblock.
I think I may have planted the idea that you could get i_blkbits from
sb->s_blocksize_bits, but I was wrong. Consider a block device. It's
blocksize is not related to the superblock of its containing filesystem.
> If
> inode->blksize and inode->blkbits were
> related (2**blkbits == blksize) , it also makes sense to me that someone
> (Ted?) removed one and left the other
> as one would be redundant,
They were never really related. Some filesystems treated them as if
they were, but the vfs always used i_blkbits for the block size.
i_blksize was only really used for returning stat->blksize.
> but some filesystems like cifs have a large
> recommended i/o size (16K),
> but if someone wants to remove both from the inode that is fine by me,
> as long as cifs
> stat->blksize is set as you suggested on the way out of cifs_getattr.
> Eventually cifs should set
> the stat->blksize to a smaller value for one rarer case. For the most
> common case
> cifs should still set it to 16K (CIFS_MAX_MSGSIZE) as that is the most
> common negotiated
> buffer size but if the server does not negotiate large read support, and
> the server also is so old
> that it negotiates a buffer size smaller than 16K (e.g. Windows95
> negotiates 2K IIRC)
> then we could set stat-blksize to the smaller negotiated buffer size -
> but since those servers are
> getting rarer it is probably not that important. More interesting
> will be the future cases in
> which we will be able to set this value larger to more servers, as in
> general for modern
> network adapters, the larger network i/o size the better.
It would probably be best to just set stat->blksize to the negotiated
buffer size.
--
David Kleikamp
IBM Linux Technology Center
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
