Comment 318 for bug 131094

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?