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: <20120914144543.GB4952@quack.suse.cz>
Date:	Fri, 14 Sep 2012 16:45:43 +0200
From:	Jan Kara <jack@...e.cz>
To:	OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>
Cc:	Jan Kara <jack@...e.cz>, 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()

On Fri 14-09-12 22:44:28, OGAWA Hirofumi wrote:
> Jan Kara <jack@...e.cz> writes:
> 
> >> page reclaim and fsync path have FS handler. So, FS can control those.
> >> 
> >> The modern FS have to control to flush carefully. Many FSes are already
> >> ignoring if wbc->sync_mode != WB_SYNC_ALL (e.g. ext3_write_inode,
> >> nilfs_writepages), and have own FS task to flush.
> >   Out of curiosity, what exactly do you need to control in your filesystem
> > that makes flusher thread unusable for you? You still have a lot of
> > flexibility with ->write_inode() and ->writepages() callbacks...
> 
> If flusher is working, it clears dirty flags of inode. But if those
> handers can't flush at the time, we have to do redirty or something to
> prevent the reclaim.
  Well, if this is your only problem then I'd see better options than just
disabling flusher thread. If the inability to write inode is rare, then
redirtying seems like a reasonable option (despite I agree it's a bit
ugly). If the inability to write is common, then you'll probably have to do
the dirty inode tracking yourself in some list and expose inodes to VM when
they are ready to be written. Or you handle writing of inodes yourself but
leave writing of pages on flusher thread...

Because when you disable flusher thread completely you have to put all the
smarts to avoid livelocks, keep fairness among processes, write old data,
keep number of dirty pages under control into your filesystem which leads
to a lot of duplication.

								Honza
-- 
Jan Kara <jack@...e.cz>
SUSE Labs, CR
--
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/