On Mon, 7 Dec 2015, Andrey Chernov wrote:
On 07.12.2015 17:42, Andrey Chernov wrote:
On 07.12.2015 15:09, Konstantin Belousov wrote:
Author: kib
Date: Mon Dec 7 12:09:04 2015
New Revision: 291936
URL: https://svnweb.freebsd.org/changeset/base/291936
Log:
Update ctime when atime or birthtime are updated.
Who calls ufs_itimes() and when to process IN_CHANGE flag in the new
version?
UFS_UPDATE() is called next and it call ufs_itimes(). Converting
IN_CHANGE from a mark to a time could be delayed safely, but the other
changes should be written soon. We use a delayed write, so they are
not actually written very soon, and this could be optimized a little.
Setting IN_LAZYACCESS might work as a hack (just some flag that the
syncer checks and calls UFS_UPDATE() to clear). Only do this for
unimportant attributes like times. For ids, I would go the other
way and tell UFS_UPDATE() to do an async update. It currently only
supports a waitfor boolean flag which selects bwrite() if set and
normally bdwrite() if clear unless under load when it selects
bawrite() if clear.
- ufs_itimes(vp);
+ ip->i_flag |= IN_CHANGE | IN_MODIFIED;
New version also forces IN_MODIFIED flag old one tends to avoid (only
for birthtime, and only for non-suspended systems in ufs_itimes()).
That was mostly obfuscation in the old version:
- for settings of the atime only, we modified the atime (possibly with
a null change) but don't set IN_MODIFIED. ufs_itimes() fixeed this
up by translating IN_ACCESS to a modification of the atime and a
setting of IN_MODIFIED. This is depends on not being in the suspended
case. Then we overwrote the modification with the final one before
writing
- for settings of the mtime only, ufs_itimes() fixes up IN_MODIFIED in
the same way except this is obviously not affected by the suspended
flag
- for settings of the birthtime only, ufs_itimes() had no effect unless
some update marks were already set, so we had to set IN_MODIFIED
directly.
The suspended case makes the side effects of ufs_itimes() even harder to
understand, except it doesn't actually occur for calls from VOP_SETATTR(),
since setattr is like write() -- it arranges for exclusive access and not
suspended.
Bruce
_______________________________________________
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
