[dm-devel] [PATCH] deadlock with suspend and quotas

[Jan Kara]

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 at suse.cz>
SUSE Labs, CR