linux-kernel - Re: [RFC]block: add flush request at head

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, 18 Apr 2011 05:26:07 -0400
From:	Christoph Hellwig <hch@...radead.org>
To:	Jens Axboe <jaxboe@...ionio.com>
Cc:	Shaohua Li <shaohua.li@...el.com>,
	lkml <linux-kernel@...r.kernel.org>,
	Tejun Heo <htejun@...il.com>, "Shi, Alex" <alex.shi@...el.com>,
	"Chen, Tim C" <tim.c.chen@...el.com>
Subject: Re: [RFC]block: add flush request at head

On Mon, Apr 18, 2011 at 10:08:52AM +0200, Jens Axboe wrote:
> Might be worth adding something for this special case, seems like the
> NCQ restrictions will continue to be around forever (or a long time, at
> least).

I heared people are working on adding a queued FLUSH to the standard,
but it's going to take a long time for it to get into real life systems.

What would help now is allowing libata to actually use the FUA bit,
given that every common disk and controller supports it these days.

Shaohua, does adding a

	libata.fua = 1

to the kernel command line help your benchmark in any way?  It should
if you flushes are mostly from journal writes, but not from fsync
that didn't change any metadata.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/