diff options
author | NeilBrown <neilb@suse.de> | 2014-09-18 08:09:27 +0200 |
---|---|---|
committer | Trond Myklebust <trond.myklebust@primarydata.com> | 2014-09-25 05:23:02 +0200 |
commit | e87b4c7a7ac6d895846570dec637744cf7050df3 (patch) | |
tree | 9268a48377b2ddb12733d108c099df3be4fd0414 /mm/filemap.c | |
parent | NFSv4: use exponential retry on NFS4ERR_DELAY for async requests. (diff) | |
download | linux-e87b4c7a7ac6d895846570dec637744cf7050df3.tar.xz linux-e87b4c7a7ac6d895846570dec637744cf7050df3.zip |
NFS: don't use STABLE writes during writeback.
commit b31268ac793fd300da66b9c28bbf0a200339ab96
FS: Use stable writes when not doing a bulk flush
was a bit heavy handed.
The particular problem that lead to this patch was that
small writes to an O_SYNC file we being written as UNSTABLE writes
followed by a commit.
This is appropriate for large writes (which require multiple NFS
requests) but for small writes (single NFS request), using
NFS_FILE_SYNC is more efficient.
So that patch causes the code to select between the two methods
depending on how many nfs requests get generated.
Unfortunately this ends up applying to non O_SYNC writes as well.
In particular if you memory-map a file and update random pages, then
when they are eventually written out by writeback they will go as
NFS_FILE_SYNC. This is inefficient and slows down the application.
So: only set FLUSH_COND_STABLE when wbc->sync_mode is WB_SYNC_ALL.
With this patch:
O_SYNC writes are NFS_FILE_SYNC for single requests, and NFS_UNSTABLE
followed by COMMIT for multiple requests
Writing immediately before close of fsync follow the same pattern.
Non-O_SYNC writes without an fsync of close eventually get flushed
out as UNSTABLE and a commit follows eventually as appropriate.
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
Diffstat (limited to 'mm/filemap.c')
0 files changed, 0 insertions, 0 deletions