linux-kernel - Re: [PATCH RFC] mm: implement write-behind policy for sequential file writes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 2 Oct 2017 14:55:28 +0300
From:   Konstantin Khlebnikov <khlebnikov@...dex-team.ru>
To:     Florian Weimer <fweimer@...hat.com>, linux-fsdevel@...r.kernel.org,
        linux-mm@...ck.org, linux-kernel@...r.kernel.org
Cc:     Jens Axboe <axboe@...nel.dk>, Michal Hocko <mhocko@...e.com>,
        Mel Gorman <mgorman@...e.de>,
        Johannes Weiner <hannes@...xchg.org>,
        Tejun Heo <tj@...nel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH RFC] mm: implement write-behind policy for sequential file
 writes

On 02.10.2017 14:23, Florian Weimer wrote:
> On 10/02/2017 11:54 AM, Konstantin Khlebnikov wrote:
>> This patch implements write-behind policy which tracks sequential writes
>> and starts background writeback when have enough dirty pages in a row.
> 
> Does this apply to data for files which have never been written to disk before?
> 
> I think one of the largest benefits of the extensive write-back caching in Linux is that the cache is discarded if the file is deleted 
> before it is ever written to disk.  (But maybe I'm wrong about this.)

Yes. I've mentioned that current policy is good for short-living files.

Write-behind keeps small files (<256kB) in cache and writes files smaller
than 1MB in background, synchronous writes starts only after 1MB.

But in other hand such files have to be written if somebody calls sync or
metadata changes are serialized by journal transactions, or memory pressure
flushes them to the disk. So this caching is very unstable and uncertain.
In some cases caching makes whole operation much slower because actual disk
write starts later than could be.