Re: [RFC][PATCH 1/2] Add a super operation for writeback

Daniel Phillips
2014-06-03T22:37:57Z

On Tuesday, June 3, 2014 8:21:55 AM PDT, Jan Kara wrote:
> On Tue 03-06-14 07:14:44, Christoph Hellwig wrote:
>> On Tue, Jun 03, 2014 at 04:05:31PM +0200, Jan Kara wrote:
> ...
> So I agree per-bdi / per-sb matters only in simple setups but machines
> with single rotating disk with several partitions and without LVM aren't
> that rare AFAICT from my experience.

Retribution is sure to be swift, terrible and eternal for anyone who dares
to
break those.

> And I agree we went for per-bdi
> flushing to avoid two threads congesting a single device leading to
> suboptimal IO patterns during background writeback.

A proposal is on the table to implement s_ops->writeback() as a per-sb
operation in such a way that nothing changes in the current per-inode path.
Good or bad approach?

> So currently I'm convinced we want to go for per-sb dirty tracking. That
> also makes some speedups in that code noticeably simpler. I'm not
convinced
> about the per-sb flushing thread - if we don't regress the multiple sb on
> bdi case when we just let the threads from different superblocks contend
> for IO, then that would be a natural thing to do. But once we have to
> introduce some synchronization between threads to avoid regressions, I
> think it might be easier to just stay with per-bdi thread which switches
> between superblocks.

Could you elaborate on the means of switching between superblocks? Do you
mean
a new fs-writeback path just for data=journal class filesystems, or are you
suggesting changing the way all filesystems are driven?

Regards,

Daniel