lkml.org 
[lkml]   [2011]   [Nov]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [dm-devel] [PATCH] deadlock with suspend and quotas
    On Wed 30-11-11 11:53:40, Mikulas Patocka wrote:
    >
    >
    > On Wed, 30 Nov 2011, Alasdair G Kergon wrote:
    >
    > > On Tue, Nov 29, 2011 at 11:19:01AM +0100, Jan Kara wrote:
    > > > So I believe the consensus was that we should not block sync or flusher
    >
    > Well, I think that not blocking sync actually doesn't help at all.
    >
    > Suppose at first that you have a perfectly-barriered filesystem --- that
    > is filesystem, that contains barriers around all code paths that could
    > possibly create dirty data. In this case it is impossible to have dirty
    > data while the filesystem is suspended. --- In this case you can call
    > sync on suspened filesystem as much as you like, sync never finds ady
    > dirty data, consequently it never tries to write anything and it can't
    > deadlock. So skipping sync has no effect.
    >
    > Suppose as a second case that you have imperfectly-barriered filesystem
    > --- that means there exists a code path that creates dirty data while the
    > filesystem is suspended. In this case if you skip sync, you are violating
    > sync semantics, because the application can create dirty data while
    > suspended, call sync while still suspended and assume that the dirty data
    > was written.
    Except that currently we are in situation c) with e.g. ext4 and xfs. We
    have perfectly-barriered filesystem *but* there are dirty bits set in this
    filesystem although we are certain there are no dirty data. This
    inconsistency between dirty bits and fact whether a page contains dirty
    data is due to way how page faults are handled. I've already tried to
    explain this in this thread in https://lkml.org/lkml/2011/11/29/109 but
    apparently I failed. I can try to explain it once more but in fact I don't
    think this technical detail makes a difference in this discussion. So in our
    situation c) skipping sync makes difference and does not break guarantees
    sync should have.

    Honza
    --
    Jan Kara <jack@suse.cz>
    SUSE Labs, CR


    \
     
     \ /
      Last update: 2011-12-01 01:05    [W:0.020 / U:0.100 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site