lkml.org 
[lkml]   [2014]   [Jun]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [RFC][PATCH 1/2] Add a super operation for writeback
    Date
    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


    \
     
     \ /
      Last update: 2014-06-04 01:01    [W:4.017 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site