[lkml]   [2006]   [Jun]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC] Slimming down struct inode
Hi Nikita,

On Wed, Jun 14, 2006 at 02:29:39PM +0400, Nikita Danilov wrote:
> Sorry, but why this operation is needed? Generic code (in fs/*.c)
> doesn't use ->i_blksize at all. If XFS wants to provide per-inode
> st_blksize, all it has to do is to store preferred buffer size in its
> file system specific inode (struct xfs_inode), and use something
> different from generic_fillattr() as its ->i_op->getattr() callback
> (xfs_vn_getattr()).

We already do this. The original questions were related to whether
i_blksize and i_blkbits need to be per-inode or per-filesystem, and
thats what I was trying to answer...

| 1) Move i_blksize (optimal size for I/O, reported by the stat system
| call). Is there any reason why this needs to be per-inode, instead
| of per-filesystem?
| 2) Move i_blkbits (blocksize for doing direct I/O in bits) to struct
| super. Again, why is this per-inode?

As to whether a new inode operation is useful/needed - *shrug* - not
really my call, I was saying we can work with whatever ends up being
the final solution, provided it keeps per-inode granularity.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2006-06-14 23:54    [W:0.063 / U:1.072 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site