On Tue, May 15, 2012 at 01:33:40PM -0400, J. Bruce Fields wrote: > 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? That _was_ going to be the basis of phase 2 of my metadata checksum patchset, but since I've been moved to other projects, I don't see that on my plate in the near future. :/ (tldr: It doesn't exist.) --D > > --b. > -- > To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
