* Commit Interval and Delayed Allocation
@ 2012-11-10 0:40 Nelson, John R
2012-11-10 2:58 ` Theodore Ts'o
0 siblings, 1 reply; 3+ messages in thread
From: Nelson, John R @ 2012-11-10 0:40 UTC (permalink / raw)
To: linux-ext4@vger.kernel.org
Hi,
Say if ext4 commits every 5 seconds, does this mean whatever is buffered for delayed allocation is flushed every 5 seconds as well?
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Commit Interval and Delayed Allocation
2012-11-10 0:40 Commit Interval and Delayed Allocation Nelson, John R
@ 2012-11-10 2:58 ` Theodore Ts'o
2012-11-13 11:37 ` Peng Tao
0 siblings, 1 reply; 3+ messages in thread
From: Theodore Ts'o @ 2012-11-10 2:58 UTC (permalink / raw)
To: Nelson, John R; +Cc: linux-ext4@vger.kernel.org
On Sat, Nov 10, 2012 at 12:40:42AM +0000, Nelson, John R wrote:
> Hi,
> Say if ext4 commits every 5 seconds, does this mean whatever is
>buffered for delayed allocation is flushed every 5 seconds as well?
No; there is a separate 30 second timer which is used for writeback
thread.
For ext3 in data=ordered mode, we will flush out dirty pages for
inodes which have been written to make sure that stale data can never
get revealed.
But in delayed allocation, there is no risk that stale data can get
revealed until we actually allocate the data blocks.
- Ted
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Commit Interval and Delayed Allocation
2012-11-10 2:58 ` Theodore Ts'o
@ 2012-11-13 11:37 ` Peng Tao
0 siblings, 0 replies; 3+ messages in thread
From: Peng Tao @ 2012-11-13 11:37 UTC (permalink / raw)
To: Theodore Ts'o; +Cc: Nelson, John R, linux-ext4@vger.kernel.org
On Sat, Nov 10, 2012 at 10:58 AM, Theodore Ts'o <tytso@mit.edu> wrote:
> On Sat, Nov 10, 2012 at 12:40:42AM +0000, Nelson, John R wrote:
>> Hi,
>> Say if ext4 commits every 5 seconds, does this mean whatever is
>>buffered for delayed allocation is flushed every 5 seconds as well?
>
> No; there is a separate 30 second timer which is used for writeback
> thread.
>
> For ext3 in data=ordered mode, we will flush out dirty pages for
> inodes which have been written to make sure that stale data can never
> get revealed.
>
> But in delayed allocation, there is no risk that stale data can get
> revealed until we actually allocate the data blocks.
>
Hi Ted,
Then ext4.txt seems need updating? If I understand you correctly, I'd
expect to lose 30 seconds of data rather than 5 seconds if data is
delayed allocated.
172 commit=nrsec (*) Ext4 can be told to sync all its data and metadata
173 every 'nrsec' seconds. The default value
is 5 seconds.
174 This means that if you lose your power,
you will lose
175 as much as the latest 5 seconds of work (your
176 filesystem will not be damaged though, thanks to the
177 journaling). This default value (or any low value)
178 will hurt performance, but it's good for
data-safety.
179 Setting it to 0 will have the same effect as leaving
180 it at the default (5 seconds).
181 Setting it to very large values will improve
182 performance.
--
Thanks,
Tao
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2012-11-13 11:37 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-11-10 0:40 Commit Interval and Delayed Allocation Nelson, John R
2012-11-10 2:58 ` Theodore Ts'o
2012-11-13 11:37 ` Peng Tao
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).