linux-ext4 - Re: [PATCH v7.1] block: Coordinate flush requests

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:	Tue, 18 Jan 2011 09:12:55 +0800
From:	Shaohua Li <shli@...nel.org>
To:	Tejun Heo <tj@...nel.org>
Cc:	djwong@...ibm.com, Jens Axboe <axboe@...nel.dk>,
	"Theodore Ts'o" <tytso@....edu>, Neil Brown <neilb@...e.de>,
	Andreas Dilger <adilger.kernel@...ger.ca>,
	Jan Kara <jack@...e.cz>, Mike Snitzer <snitzer@...hat.com>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Keith Mannthey <kmannth@...ibm.com>,
	Mingming Cao <cmm@...ibm.com>, linux-ext4@...r.kernel.org,
	Ric Wheeler <rwheeler@...hat.com>,
	Christoph Hellwig <hch@....de>, Josef Bacik <josef@...hat.com>
Subject: Re: [PATCH v7.1] block: Coordinate flush requests

2011/1/16 Tejun Heo <tj@...nel.org>:
> Hello,
>
> On Fri, Jan 14, 2011 at 09:00:22AM +0800, Shaohua Li wrote:
>> it appears we can easily implement this in blk_do_flush, I had
>> something at my hand too, passed test but no data yet.
>
>> Task1: ...FS.....C
>> Task2: ....F......S...C
>> Task3: ......F.........S..C
>> F means a flush is queued, S means a flush is dispatched, C means the flush
>> is completed. In above, when Task2's flush is completed, we actually can
>> make Task3 flush complete, as Task2's flush is dispatched after Task3's flush
>> is queued. With the same reason, we can't merge Task2 and Task3's flush with
>> Task1's.
>
> I think this is the correct direction but we can take it further.  The
> only thing block layer has to guarantee is (ignoring FUA support),
>
> * If the flush request is empty, at least one flush is executed upon
>  its completion.
>
> * If the flush request is not empty, the payload is written only after
>  a preceding flush and follwed by another flush if requested.
>
> So, if we can combine N flushes with or without data,
>
>  PREFLUSH -> N flush data payloads -> POSTFLUSH
This makes sense. would it possible N flush data payloads delay the
first request?

> The following is something I hacked past few hours.  I just made it
> compile so it's definitely horridly broken.  Please don't try to even
> test it, but it should still give an idea about the direction.  I'll
> try to finish this early next week.
I'm looking forward to seeing it.

Thanks,
Shaohua
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html