> On Thu 13-08-15 18:44:15, Tejun Heo wrote:
> > e79729123f63 ("writeback: don't issue wb_writeback_work if clean")
> > updated writeback path to avoid kicking writeback work items if there
> > are no inodes to be written out; unfortunately, the avoidance logic
> > was too aggressive and made sync_inodes_sb() skip I_DIRTY_TIME inodes.
> > This patch fixes the breakage by
> > * Removing bdi_has_dirty_io() shortcut from bdi_split_work_to_wbs().
> > The callers are already testing the condition.
> > * Removing bdi_has_dirty_io() shortcut from sync_inodes_sb() so that
> > it always calls into bdi_split_work_to_wbs().
> > * Making bdi_split_work_to_wbs() consider the b_dirty_time list for
> > WB_SYNC_ALL writebacks.
> > Signed-off-by: Tejun Heo <tj@xxxxxxxxxx>
> > Fixes: e79729123f63 ("writeback: don't issue wb_writeback_work if clean")
> > Cc: Ted Ts'o <tytso@xxxxxxxxxx>
> > Cc: Jan Kara <jack@xxxxxxxx>
* Jan Kara <jack@xxxxxxx> [2015-08-14 13:14]:
> So the patch looks good to me. But the fact that is fixes Eryu's problem
> means there is something fishy going on. Either inodes get wrongly attached
> to b_dirty_time list or bdi_has_dirty_io() somehow misbehaves only
> temporarily and we don't catch it with the debug patch.
> Can we add a test to wb_has_dirty_io() to also check whether it matches
> bdi_has_dirty_io()? Since Eryu doesn't use lazytime (I assume, Eryu, please
> speak up if you do), we could also warn if b_dirty_time lists get
> non-empty. Hmm?
Hi,
I had an unstable system when running latest Linus tree with Tejun's
patch applied on top. Nothing fishy in the logs after rebooting without
the patch, but remote access with ssh when patch applied did not work
(as if /home partition could not be read). This system has / as ext4 and
other partitions (including /home) as XFS. Trying to login on tty
instead of X resulted in hang of X. I could reboot with sysrq, but can't
do further tests at the moment.
Back to same tree without the patch resulted in normal system.
So just a heads up the patch doesn't seem OK in its current state.
Cheers
Damien
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
