linux-kernel - Re: [PATCH] Fix queueing work if !bdi_cap_writeback

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]

Message-ID: <87wqzt7drb.fsf@devron.myhome.or.jp>
Date:	Mon, 17 Sep 2012 08:24:08 +0900
From:	OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>
To:	Jan Kara <jack@...e.cz>
Cc:	Fengguang Wu <fengguang.wu@...el.com>, viro@...iv.linux.org.uk,
	hch@....de, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Fix queueing work if !bdi_cap_writeback_dirty()

Jan Kara <jack@...e.cz> writes:

>> I'm not sure what you meant though. What is the difference with ignoring
>> WBC_SYNC_NONE?
>   When you completely ignore WB_SYNC_NONE writeback, you'll soon drive the
> machine close to dirty limits and processes dirtying pages will get
> throttled. Because flusher threads won't be able to write pages - they
> do WB_SYNC_NONE writeback when we have too many dirty pages - processes
> will be throttled until somebody calls sync(1) or someone writes the data
> for some other reason... So I suspect things won't really work as you
> expect.

I think you know how to solve it though. You can add the periodic flush
in own task. And you can check bdi->dirty_exceeded in any handlers.

Well, ok. The alternative plan but more bigger change is to add the
handler to writeback task path. This would be better way, and core
should be able to request to flush with usual way (I guess this is what
you are concerning).  And I believe some FS can implement the simpler
and more efficient writeback path.

But this would look like what reiserfs4 was submitted in past (before
bdi was introduced), and unfortunately never accepted though.

Since situation was changed, will we accept it?

OK, why my FS requires it? Because basic strategy try to keep the
consistency of user view, not only internal metadata consistency.
I.e. it works like to flush the snapshot of user view.

So, flushing metadata/data by arbitrary order like current writeback
task does is unacceptable (of course, except request by user). And
writeback task will never know the correct order of FS.

Thanks.
-- 
OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>
--
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/