On Wed, Apr 22, 2015 at 09:15:09AM -0700, Christoph Hellwig wrote:
> On Wed, Apr 22, 2015 at 10:37:46AM -0400, Brian Foster wrote:
> > There are probably a couple different ways to handle this. We could log
> > the inode in the bmap cases in order to preserve the pincount check.
>
> I'd favor that. For one performance should be better, second we really
> need to dirty the inode anyway for v5 file systems as that's the
> mechanism used to increment di_changecount.
>
Yeah, that's a good point. I noticed that in xfs_trans_log_inode() when
debugging but didn't think much about it since I reproduced on v4. I can
get performance back with the aforementioned cil push fix, but if the
path forward is behavior where the inode is going to be logged anyways,
that is decent reason to emulate such behavior in the pre-v5 case.
Note that we have the following in xfs_bmapi_write():
if (bma.logflags)
xfs_trans_log_inode(tp, ip, bma.logflags);
... and some other places. I don't reproduce this particular problem on
v5, so something else might be logging the inode here. That strikes me
as not what we want with regard to the change count, however..
Brian
> _______________________________________________
> xfs mailing list
> xfs@xxxxxxxxxxx
> http://oss.sgi.com/mailman/listinfo/xfs
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
