It is relatively common for new writes to occur to a file concurrent with
fsync(2) on that file. Do not produce a spammy warning in that case, even
in INVARIANTS mode.
Details
- Reviewers
mckusick kib imp - Commits
- rS336280: ffs_syncvnode: Remove unhelpful print
Diff Detail
- Lint
Lint Passed - Unit
No Test Coverage - Build Status
Buildable 18013 Build 17765: arc lint + arc unit
Event Timeline
It is not common for new writes to occur, because fsync() locks the vnode and that blocks writers. It is usually softdep re-dirtying the buffers which cause ffs_syncvnode() to loop long.
But I did not see any use for this messages anyway.
Oh, good point. I had forgotten about that. Does that also block mmap writes?
It is usually softdep re-dirtying the buffers which cause ffs_syncvnode() to loop long.
But I did not see any use for this messages anyway.
Can it occur in other situations? We have seen it a few times over the last decade, even with SU disabled. Often the associated process was syslogd.
It cannot block writes to the mmaped pages. But running fsync does not see them.
Dirty pages needs to be converted to the dirty buffers, this is done by the vm_object_clean_pages() function, which is typically called by the syncer, see vfs_msync(). Since the function needs the vnode locked, it is blocked by the running fsync.
OTOH, when the buffer is prepared for write, all its pages are remapped r/o, see vfs_busy_pages(). So the pages of the dirty buffer found by the loop cannot be modified while write is performed.
It is usually softdep re-dirtying the buffers which cause ffs_syncvnode() to loop long.
But I did not see any use for this messages anyway.
Can it occur in other situations? We have seen it a few times over the last decade, even with SU disabled. Often the associated process was syslogd.
I can only think about failing writes re-dirtying the buffers with error.