In D16258#344889, @kib wrote:

It is not common for new writes to occur, because fsync() locks the vnode and that blocks writers.

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.

In D16258#345031, @cem wrote:

In D16258#344889, @kib wrote:

It is not common for new writes to occur, because fsync() locks the vnode and that blocks writers.

Oh, good point. I had forgotten about that. Does that also block mmap writes?

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.

In D16258#345051, @kib wrote:

In D16258#345031, @cem wrote:

In D16258#344889, @kib wrote:

It is not common for new writes to occur, because fsync() locks the vnode and that blocks writers.

Oh, good point. I had forgotten about that. Does that also block mmap writes?

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.

Thanks!

In D16258#345051, @kib wrote:

I can only think about failing writes re-dirtying the buffers with error.

...and that code is likely to disappear soon.