confused by delayed allocation and ordered journal

confused by delayed allocation and ordered journal

[Yongqiang Yang]

Hi all,

I found that if a block'allocation is delayed, and is not allocated
when journal flushes it, then journal just redirties it and return in
journal_submit_data_buffers.

If I understand right, how to guarantee that the journal mode is ordered?

Thanks,
Yongqiang.
-- 
Best Wishes
Yongqiang Yang

Re: confused by delayed allocation and ordered journal

[Ted Ts'o]

On Sat, Dec 25, 2010 at 09:15:28PM +0800, Yongqiang Yang wrote:
> 
> I found that if a block'allocation is delayed, and is not allocated
> when journal flushes it, then journal just redirties it and return in
> journal_submit_data_buffers.
> 
> If I understand right, how to guarantee that the journal mode is ordered?

The primary goal of ordered mode is to make sure that stale data is
not exposed after a crash.  To the extent that delayed allocation also
achieves this goal, it's fine.  The fact that ext3 forced data blocks
out as part of its jbd commit function was always an implementation
detail.

In the long run we'll be getting rid of ordered mode even more so, by
writing the data block first, and only then updating the file system
metadata.  At that point there will be no ordered flushing at all, and
in fact ordered mode will go away as a journal mode supported by ext4.

   		     	     	  - Ted

Re: confused by delayed allocation and ordered journal

[Amir Goldstein]

On Sat, Dec 25, 2010 at 4:39 PM, Ted Ts'o <tytso@mit.edu> wrote:
> On Sat, Dec 25, 2010 at 09:15:28PM +0800, Yongqiang Yang wrote:
>>
>> I found that if a block'allocation is delayed, and is not allocated
>> when journal flushes it, then journal just redirties it and return in
>> journal_submit_data_buffers.
>>
>> If I understand right, how to guarantee that the journal mode is ordered?
>
> The primary goal of ordered mode is to make sure that stale data is
> not exposed after a crash.  To the extent that delayed allocation also
> achieves this goal, it's fine.  The fact that ext3 forced data blocks
> out as part of its jbd commit function was always an implementation
> detail.

Hi Ted,

FYI, Yongqiang is researching move-on-write of extent mapped files
data and opportunistic de-fragmentation on rewrite
and this is the context of his question.

As I mentioned to you on Plumbers the ordering requirements for move-on-write
are a bit stronger than "not exposing un-initialized data".
In the process of move-on-write, the extent must always map written data blocks
and traditional 'ordered' mode can be used to guaranty that.

Yongqiang,

I believe in the case of delalloc move-on-rewrite, on write_begin(),
you only need to reserve blocks (in-memory)
and on writepages(), you do the actual move-on-write, modifying the
extent from one valid data blocks range to another.


>
> In the long run we'll be getting rid of ordered mode even more so, by
> writing the data block first, and only then updating the file system
> metadata.  At that point there will be no ordered flushing at all, and
> in fact ordered mode will go away as a journal mode supported by ext4.
>

And that can simplify move-on-write implementation as well.
But until that happens, snapshots will require 'ordered' mode.

Amir.
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html