linux-kernel - Re: [PATCH 07/10] fs: make generic file read/write functions plug

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20110304140814.GA28953@infradead.org>
Date:	Fri, 4 Mar 2011 09:08:14 -0500
From:	"hch@...radead.org" <hch@...radead.org>
To:	Jens Axboe <jaxboe@...ionio.com>
Cc:	"hch@...radead.org" <hch@...radead.org>,
	Vivek Goyal <vgoyal@...hat.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 07/10] fs: make generic file read/write functions plug

On Fri, Mar 04, 2011 at 02:40:09PM +0100, Jens Axboe wrote:
> > REQ_META?  Maybe we should finally agree what it does and decide if it
> > should be used consistenly.  Especially the priority over REQ_SYNC in
> > cfq still looks somewhat odd, as does the totally inconsequent use.
> 
> For me it was primarily a blktrace hint, but yes it does have prio boost
> properties in CFQ as well. I'm inclined to let those stay the way they
> are. Not sure we can properly call it anything outside of a hint that
> these IO have slightly higher priority, at least I would not want to
> lock the IO scheduler into to something more concrete than that.

The problem is that these two meanings are inherently conflicting.
Metadata updates do not have to be synchronous or have any kind of
priority.  In fact for XFS they normall aren't, and I'd be surprised it
the same isn't true for other journalled filesystems.

Priority metadata goes into the log, which for XFS is always written as
a FLUSH+FUA bio.  Writeback of metadata happens asynchronously in the
background, and only becomes a priority if the journal is full and we'll
need to make space available.

So giving plain REQ_META a priority boost makes it impossible to use it
for the blktrace annotation use case.  One could only apply the boost
for the REQ_SYNC + REQ_META combination, but even that seems rather
hackish to me.  I'd really love to see numbers where the additional
boost of REQ_META over REQ_SYNC makes any difference.

--
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/