Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1257851
| From | Andres Freund <andres@anarazel.de> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: Triggering non-integrity writeback from userspace |
| Date | 2015-10-28 10:30 +0100 |
| Message-ID | <qovdo-Lu-23@gated-at.bofh.it> (permalink) |
| References | <qmo6m-3GO-1@gated-at.bofh.it> <qneHE-48s-19@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
Hi,
Thanks for looking into this.
On 2015-10-25 08:39:12 +1100, Dave Chinner wrote:
> WB_SYNC_ALL is simply a method of saying "writeback all dirty pages
> and don't skip any". That's part of a data integrity operation, but
> it's not what results in data integrity being provided. It may cause
> some latencies caused by blocking on locks or in the request queues,
> so that's what I'd be looking for.
It also means we'll wait for more:
int write_cache_pages(struct address_space *mapping,
struct writeback_control *wbc, writepage_t writepage,
void *data)
{
...
if (wbc->sync_mode == WB_SYNC_ALL || wbc->tagged_writepages)
tag = PAGECACHE_TAG_TOWRITE;
else
tag = PAGECACHE_TAG_DIRTY;
...
if (PageWriteback(page)) {
if (wbc->sync_mode != WB_SYNC_NONE)
wait_on_page_writeback(page);
else
goto continue_unlock;
}
> i.e. if the request queues are full, SYNC_FILE_RANGE_WRITE will
> block until all the IO it has been requested to write has been
> submitted to the request queues. Put simply: the IO is asynchronous
> in that we don't wait for completion, but the IO submission is still
> synchronous.
That's desirable in our case because there's a limit to how much
outstanding IO there is.
> Data integrity operations require related file metadata (e.g. block
> allocation trnascations) to be forced to the journal/disk, and a
> device cache flush issued to ensure the data is on stable storage.
> SYNC_FILE_RANGE_WRITE does neither of these things, and hence while
> the IO might be the same pattern as a data integrity operation, it
> does not provide such guarantees.
Which is desired here - the actual integrity is still going to be done
via fsync(). The idea of using SYNC_FILE_RANGE_WRITE beforehand is that
the fsync() will only have to do very little work. The language in
sync_file_range(2) doesn't inspire enough confidence for using it as an
actual integrity operation :/
> > If I followed the code correctly - not a sure thing at all - that means
> > bios are submitted with WRITE_SYNC specified. Not really what's needed
> > in this case.
>
> That just allows the IO scheduler to classify them differently to
> bulk background writeback.
It also influences which writes are merged and which are not, at least
if I understand elv_rq_merge_ok() and the callbacks it calls..
> You don't want to do writeback from the syscall, right? i.e. you'd
> like to expire the inode behind the fd, and schedule background
> writeback to run on it immediately?
Yes, that's exactly what we want. Blocking if a process has done too
much writes is fine tho.
Greetings,
Andres Freund
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Triggering non-integrity writeback from userspace Andres Freund <andres@anarazel.de> - 2015-10-22 15:30 +0200
Re: Triggering non-integrity writeback from userspace Dave Chinner <david@fromorbit.com> - 2015-10-24 23:40 +0200
Re: Triggering non-integrity writeback from userspace Andres Freund <andres@anarazel.de> - 2015-10-28 10:30 +0100
Re: Triggering non-integrity writeback from userspace Dave Chinner <david@fromorbit.com> - 2015-10-28 21:50 +0100
Re: Triggering non-integrity writeback from userspace Dave Chinner <david@fromorbit.com> - 2015-10-29 00:30 +0100
Re: Triggering non-integrity writeback from userspace Andres Freund <andres@anarazel.de> - 2015-10-29 00:30 +0100
Re: Triggering non-integrity writeback from userspace Dave Chinner <david@fromorbit.com> - 2015-10-29 03:00 +0100
Re: Triggering non-integrity writeback from userspace Andres Freund <andres@anarazel.de> - 2015-10-29 17:30 +0100
Re: Triggering non-integrity writeback from userspace Dave Chinner <david@fromorbit.com> - 2015-10-29 23:20 +0100
Re: Triggering non-integrity writeback from userspace Jan Kara <jack@suse.cz> - 2015-10-25 05:20 +0100
csiph-web