On Thu, Mar 03, 2011 at 01:42:28PM +1100, Dave Chinner wrote:
> Yeah, it doesn't seem like there's an easy way around that. I guess
> I'll start by tracking VFS dirty inodes via a tag in the per-ag radix
> tree and kick writeback via a new xfssynd work operation. I'll see
> if that is sufficient to avoid the OOM problem without needing to
> log the inodes in the .dirty_inode callback or changing it's
> prototype.
I don't think we'll be able to get around chaning the dirty_inode
callback. We need a way to prevent the VFS from marking the inode
dirty, otherwise we have no chance of reclaiming it.
Except for that I think it's really simple:
1) we need to reintroduce the i_update_size flag or an equivalent to
distinguish unlogged timestamp from unlogged size updates for fsync
vs fdatasync. At that point we can stop looking at the VFS dirty
bits in fsync.
2) ->dirty_inode needs to tag the inode as dirty in the inode radix
tree
With those minimal changes we should be set - we already
callxfs_sync_attr from the sync_fs path, and xfs_sync_inode_attr
properly picks up inodes with unlogged changes.
In fact that whole scheme might even be able to speed up sync - right
now we first log the inode and then flush all pending data in the log
back to disk, and with this scheme we avoid logging the inode in the
first place.
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
