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

[Daniel Phillips]

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
--
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/