Re: [PATCH] Fix queueing work if !bdi_cap_writeback_dirty()

[Jan Kara]

On Mon 17-09-12 08:24:08, OGAWA Hirofumi wrote:
> Jan Kara <jack@xxxxxxx> 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.
  Sure, you can have your private thread. That is possible but you will
have to duplicate flusher logic and you will still get odd behavior e.g.
when your filesystem is on one partition and another filesystem is on a
different partition of the same disk.

> 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.
  OK, thanks for explanation. Now I understand what you are trying to do.
Would it be enough if you could track dirty inodes inside your filesystem
and provide some callback for flusher so that you can queue these inodes in
the IO queue?

								Honza
-- 
Jan Kara <jack@xxxxxxx>
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/