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: <4D7162B7.20101@fusionio.com>
Date:	Fri, 4 Mar 2011 23:07:51 +0100
From:	Jens Axboe <jaxboe@...ionio.com>
To:	"hch@...radead.org" <hch@...radead.org>
CC:	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 2011-03-04 15:08, hch@...radead.org wrote:
> 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.

Seems only gfs2 actually sets the flag now. So how about we remove the
prio boost for meta data and just retain it as an information attribute?

If there's a need for this slight boosts, it is probably best done
explicitly being signalled from the caller.

-- 
Jens Axboe

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