On Mon, 14 Mar 2011 17:11:19 -0400
"Ted Ts'o" [off-list ref] wrote:
On Mon, Mar 14, 2011 at 01:10:42PM -0700, Andrew Morton wrote:
quoted
There might one day be a requirement to be able to initiate a
resource-management-style writeback against a whole filesystem. When
that happens, we'll regret not having added a "mode" argument to
sys_syncfs().
I'm a bit nervous about exposing WB_SYNC_NONE to userspace, because
its semantics are *definitely* hard to describe. For example, at the
moment if you do a WB_SYNC_NONE writeback, the writeback code will
clamp the amount of data written back for each inode to
MAX_WRITEBACK_PAGES (1024) pages.
Wha? It does? When did that get broken?
Do we want to document that?
Probably not! But if we don't document it, what can userspace expect?
If you just issue a writeback_inodes_sb(), it's not the case that it
will start a process that will eventually write out everything (i.e.,
it's not the equivalent of a non-blocking data integrity sync). It
just means, "write out some stuff".
I could imagine userspace wanting to start a non-blocking writeout of
all data blocking pages, and which doesn't cause queue flush / barrier
requests. (i.e., a non-blocking-non-barrier-issuing-but-otherwise-a-
data-integrity writeback) But that's not something that the current
writeback machinery can do easily, at least not today.
Well. Current implementation shortcomings don't carry a lot of weight
when designing a permanent interface.
quoted hunk ↗ jump to hunk
It wouldn't hurt to have a "flags" field which we could expand later
--- but that can lead to portability headaches for userspace programs
that don't know whether a particular kernel is going to support a
particular flag or not. So it's certainly not a panacea.
I don't see a need to add an arg to syncfs() really. But we should
demonstrate that we've thought about it ;)