Messages in this thread | | | From | Daniel Phillips <> | Subject | Re: [RFC][PATCH 1/2] Add a super operation for writeback | Date | Tue, 03 Jun 2014 15:37:39 -0700 |
| |
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
| |