Comment 317 for bug 131094

Revision history for this message
Johannes H. Jensen (joh) wrote : Re: [Bug 131094] Re: Heavy Disk I/O harms desktop responsiveness

So I just tested writeback on my desktop computer which exhibits the
same problems. I mounted both the root filesystem and /home with
data=writeback (ext3).

So far the difference is *huge*! The system is much more responsive -
I'm writing this while 'stress -d 4' is running in the background. The
same applies to the dd test - all apps respond almost instantly with
writeback, as opposed to sluggish and hanging with ordered.
Applications open much faster as well....

I'll do some more testing to confirm - mainly writeback only on /home
vs root and also on my laptop. Is this a bug in ext3 then, or is
ordered mode supposed to be so slow / problematic on desktop systems?
What problems might occur when using writeback mode? I'm a bit
concerned about the following comment from the mount manual:

It guarantees internal filesystem integrity, however it can
allow old data to appear in files after a crash and journal recovery.

By the way, to use writeback on the root filesystem, setting
data=writeback in fstab only is not sufficient. As 'man mount' states:

To use modes other than ordered on the root filesystem, pass the
mode to the kernel as boot parameter, e.g. rootflags=data=journal.

- Johannes

On Wed, Jun 23, 2010 at 11:52 AM, Johannes H. Jensen
<email address hidden> wrote:
> I haven't tried writeback, no. Is it possible to remount with this
> option, or do I need to modify fstab and reboot?
>
> - Johannes
>
>
> On Wed, Jun 23, 2010 at 10:00 AM, Peter Hoeg <email address hidden> wrote:
>> Have you tried mounting the filesystems with writeback instead of
>> ordered?
>>
>> /peter
>>
>> On Wed, Jun 23, 2010 at 15:42, Johannes H. Jensen <email address hidden> wrote:
>>> I just tested with the anticipatory scheduler on the stock Ubuntu
>>> 2.6.32:
>>>
>>> # echo anticipatory > /sys/block/sda/queue/scheduler
>>>
>>> This did not seem to have any effect - the problem was still very much
>>> present.
>>>
>