On Mon, May 14, 2012 at 11:27:42AM -0600, Andreas Dilger wrote: > On 2012-05-14, at 9:23 AM, J. Bruce Fields wrote: > > On Mon, May 14, 2012 at 09:02:12AM -0600, Andreas Dilger wrote: > >> On 2012-05-14, at 8:06, "J. Bruce Fields" <bfields@xxxxxxxxxxxx> wrote: > >>> knfsd needs i_version updates on, as will userspace nfs servers and > >>> probably others. > >>> > >>> The only effects are that inode->i_version is bumped (under the i_lock) > >>> in more places, and that ->dirty_inode(I_DIRTY_DATASYNC) may be called > >>> more frequently than once per jiffy on write (see file_update_time). > >>> However the latter appears to be mostly a no-op in that case. > >> > >> I thought this can have noticeable performance impact, since ext4_mark_inode_dirty() is quite heavyweight? > > > > There's no reason it should be, should it, if we already just dirtied > > the inode a moment ago? > > Ideally not, but the way ext[34]_mark_inode_dirty() is implemented > is that it copies the whole in-core inode to the on-disk inode every > time it is marked dirty. That ensures that the on-disk inode is > up-to-date when the journal flushes the blocks to disk, but is not > an ideal implementation. It has been this way since the first ext3 > implementation was done. > > As a result, dirtying the inode very frequently for ext[34] is > currently expensive and should be avoided. > > I _think_ that the ext4 metadata checksum patches have changed this > to only flag the inode dirty and run a pre-commit callback to copy > the in-core inode to the on-disk inode. I'm not sure what the > current status of that patch is, nor how easily it could be split > from that patch series and land separately. I did some searching, found a couple of versions of the metadata checksum patches, but no patch that looked like what you're describing. Any idea where that is? --b. -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
