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@xxxxxxx> SUSE Labs, CR -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
