Comment 322 for bug 131094

Ravindran,

Did you boot with the kernel parameter rootflags=data=writeback?

- Johannes

On Thu, Jun 24, 2010 at 7:45 AM, Ravindran K <email address hidden> wrote:
> On Thu, Jun 24, 2010 at 1:48 AM, Johannes H. Jensen
> <email address hidden>wrote:
>
>> 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.
>> >>>
>> >
>>
>> --
>> Heavy Disk I/O harms desktop responsiveness
>> https://bugs.launchpad.net/bugs/131094
>> You received this bug notification because you are a direct subscriber
>> of the bug.
>>
>> Status in The Linux Kernel: Invalid
>> Status in “linux” package in Ubuntu: Confirmed
>> Status in “linux-source-2.6.22” package in Ubuntu: Won't Fix
>>
>> Bug description:
>> Binary package hint: linux-source-2.6.22
>>
>> When compared with 2.6.15 in feisty, heavy disk I/O causes increased iowait
>> times and affects desktop responsiveness in 2.6.22
>>
>> this appears to be a regression from 2.6.15 where iowait is much lower and
>> desktop responsiveness is unaffected with the same I/O load
>>
>> Easy to reproduce with tracker - index the same set of files with 2.6.15
>> kernel and 2.6.22 kernel and the difference in desktop responsiveness is
>> massive
>>
>> I have not confirmed if a non-tracker process which does heavy disk i/o
>> (especially writing) replicates this yet - will do further investigation
>> soon
>>
>> To unsubscribe from this bug, go to:
>> https://bugs.launchpad.net/linux/+bug/131094/+subscribe
>>
>
> I'm using Ext4 and when I try to use data=writeback for my root partiton (it
> was ext3 and converted to ext4), I get a error while booting which indicates
> "unable to change mode from ordered to writeback while remounting".. I think
> it is another bug.. Anyone else seeing this?
>
> --
> Heavy Disk I/O harms desktop responsiveness
> https://bugs.launchpad.net/bugs/131094
> You received this bug notification because you are a direct subscriber
> of the bug.
>