On Thu, May 22, 2008 at 08:10:50PM +0200, Miklos Szeredi wrote:
> But there are quite a few others which don't call inode_setattr (which
> means that the unchanged time optimization is lost), or which do
> something possibly slow in their ->setattr():
>
> adfs, 9p, afs, coda, gfs2 ...
>
> just to name a few at the start of the alphabet.
>
> So it looks to me as this could cause some unintended performance
> regressions in these filesystems.
Actually, there's worse one: ext3. It *does* call inode_setattr(),
all right, but then it proceeds to call ext3_orphan_del(). Which
will
lock_super(inode->i_sb);
if (list_empty(&ei->i_orphan)) {
unlock_super(inode->i_sb);
return 0;
}
and bugger off, but...
* it's going to cost us
* code in _caller_ is bogus - we call that sucker regardless of
whether we had ATTR_SIZE in ia_valid
And there's one more problem, promising very ugly code review: locking
rules for notify_change() had suddenly changed - you are calling it
without i_mutex now. And ext3_setattr() is not happy - especially due
to this blind call of ext3_orphan_del() in there. We can easily fix
that one, but you'll need to audit the rest of instances...
--
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
