linux-kernel - Re: [f2fs-dev] [PATCH] f2fs: fix double count on issued discard commands

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] [day] [month] [year] [list]

Message-ID: <20170913084830epcms1p8a0a01f9de4c8f09730206203b9969a79@epcms1p8>
Date:   Wed, 13 Sep 2017 08:48:30 +0000
From:   Daeho Jeong <daeho.jeong@...sung.com>
To:     "linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-f2fs-devel@...ts.sourceforge.net" 
        <linux-f2fs-devel@...ts.sourceforge.net>
Subject: Re: [f2fs-dev] [PATCH] f2fs: fix double count on issued discard
 commands

> Actually, we didn't change priority of discard command, so that it is still
> synchronous IO for I/O scheduler, hence I/O interference will still exist if we
> try to issue discard without IO aware ability.
 
> Of course we can change the priority of discard command to lower, but potential
> issue is that with ROW I/O scheduler in kernel or FTL, async I/O will handle
> very slowly in heavy load scenario, if we are going to trigger sync write IO in
> place in where we're doing async discard, we will face long latency.
 
> Still I think it is worth to build the ability to issue async discard as a part
> of discard policy and later we can adjust policy based on different scenario.
 
> Thanks,

Oh, I see.

f2fs is sending discard requests as "sync" requests, I didn't know that.
Right, I just though in case of CFQ I/O scheduler, but f2fs has to consider the other
schedulers, but CFQ.

Thanks, :)