From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeff Moyer Subject: Re: Read starvation by sync writes Date: Wed, 23 Jan 2013 12:35:43 -0500 Message-ID: References: <20121210221222.GA25700@quack.suse.cz> <20121212101108.GC18885@quack.suse.cz> <50C8A07B.6040508@kernel.dk> <50C9D882.7000808@kernel.dk> <20121213150255.GA21592@quack.suse.cz> <50CA1884.6050408@kernel.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Jan Kara , Shaohua Li , linux-fsdevel@vger.kernel.org, LKML To: Jens Axboe Return-path: In-Reply-To: <50CA1884.6050408@kernel.dk> (Jens Axboe's message of "Thu, 13 Dec 2012 19:03:48 +0100") Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org Jens Axboe writes: >>> The problem is really that the WRITE_SYNC is (for Jan's case) behaving >>> like buffered writes, so it eats up a queue of requests very easily. On >>> the allocation side, the assumption is that WRITE_SYNC behaves like >>> dependent reads. Similar to a dd with oflag=direct, not like a flood of >>> requests. For dependent sync writes, our current behaviour is fine, we >>> treat them like reads. For commits of WRITE_SYNC, they should be treated >>> like async WRITE instead. >> Yeah. But it's similar to what happens when you run fsync() on a large >> dirty file. That will also submit a lot of WRITE_SYNC requests... kjournald >> could probably use WRITE instead of WRITE_SYNC for large commits. It's just >> that we don't really want to give e.g. DIO a preference over kjournald >> because transaction commit can effectively block any metadata changes on >> the filesystem. > > Sure, I'm not advocating against changing WRITE_SYNC, we just need to be > able to handle it a bit better. I've got a test patch, will post it > later. Jens, did you ever post your test patch? -Jeff