Re: [RFC] ext4: Semantics of delalloc,data=ordered

[Jan Kara <jack@suse.cz>]

On Mon 16-06-08 14:22:24, Eric Sandeen wrote:
> Jan Kara wrote:
> >>>   Imagine you have a file with blocks 1 and 3 allocated and block 2 is a
> >>> hole. You write blocks 1-3. Block 2 isn't allocated because of delalloc.
> >>> Now if inode is already in the current transaction's list, during commit
> >>> writes to blocks 1 and 3 will land on disk but write to block 2 will
> >>> happen only after pdflush finds it.
> >> And that should be fine with data=ordered mode right ?. Because since
> >> block 2 is not yet allocated we don't have associated meta-data. So
> >> even if we crash we have meta-data pointing to 1 and 3 and not 2. The
> >> problem is only when we write the meta-data pointing to block 2 and not
> >> block 2 itself ?.
> >   Yes, it is correct. I may be just surprising (we didn't do things like
> > this in data=ordered mode before).
> 
> Will it even be surprising?  "fill-in-hole; crash;" today may give you
> the same thing, right?  It's just that with delalloc it might be a
> bigger window in time for this to happen?
  Thinking more about it, yes, it could happen even with current ordered
mode. If the crash happens between writeback of data buffers and commit of
transaction, block in the middle would remain to be a hole.
  OK, so we just make the window larger. You are starting to convince me
that 1) is really the better choice ;).

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