Disk Operation Storms (ext4)

[Michael Titke]

I tried an installation with the ext4 file system on the system partition. Sometimes - once a day or every two days - I had what I call a disk operation storm: a lot of disk activity on the physical hard disk, unresponsive mouse cursor, bad performance for some seconds. These are usually symptoms of too much load or swap activity.
  Further investigation did not reveal any system load during the disk operation storms nor any swap activity in the system monitor. There wasn't even displayed any disk activity in the system monitor while the external hard disks LED blinked to signal activity and made the usual sounds of a lot of small synced disc io operations.

My solution to that problem was to revert back to the ext3 file system. You can do this by changing the corresponding entry in /etc/fstab from ext4 to ext3 as they are backwards compatible. Since that change and the reboot I have not again experienced a disk operating storm. The ext3 file system is journaled, all purpose and well suited to desktop operation.

ProblemType: Bug
DistroRelease: Ubuntu 15.04
Package: linux-image-3.19.0-15-generic 3.19.0-15.15 [modified: boot/vmlinuz-3.19.0-15-generic]
ProcVersionSignature: Ubuntu 3.19.0-15.15-generic 3.19.3
Uname: Linux 3.19.0-15-generic x86_64
NonfreeKernelModules: wl
ApportVersion: 2.17.2-0ubuntu1
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: mt 1449 F.... pulseaudio
CurrentDesktop: Unity
Date: Tue Jun 16 08:09:02 2015
HibernationDevice: RESUME=UUID=df8c609c-a8cf-4e53-ae6d-c754aa1ead9b
InstallationDate: Installed on 2015-06-08 (7 days ago)
InstallationMedia: Ubuntu 15.04 "Vivid Vervet" - Release amd64 (20150422)
MachineType: Apple Inc. MacBook4,1
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz root=/dev/sda3 splash quiet
RelatedPackageVersions:
 linux-restricted-modules-3.19.0-15-generic N/A
 linux-backports-modules-3.19.0-15-generic N/A
 linux-firmware 1.143
SourcePackage: linux
UdevLog: Error: [Errno 2] No such file or directory: '/var/log/udev'
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 02/09/08
dmi.bios.vendor: Apple Inc.
dmi.bios.version: MB41.88Z.00C1.B00.0802091535
dmi.board.asset.tag: Base Board Asset Tag
dmi.board.name: Mac-F22788A9
dmi.board.vendor: Apple Inc.
dmi.board.version: PVT
dmi.chassis.asset.tag: Asset Tag#
dmi.chassis.type: 2
dmi.chassis.vendor: Apple Inc.
dmi.chassis.version: Mac-F22788A9
dmi.modalias: dmi:bvnAppleInc.:bvrMB41.88Z.00C1.B00.0802091535:bd02/09/08:svnAppleInc.:pnMacBook4,1:pvr1.0:rvnAppleInc.:rnMac-F22788A9:rvrPVT:cvnAppleInc.:ct2:cvrMac-F22788A9:
dmi.product.name: MacBook4,1
dmi.product.version: 1.0
dmi.sys.vendor: Apple Inc.

[Brad Figg (brad-figg)]

This change was made by a bot.

[Joseph Salisbury (jsalisbury)]

Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v4.1 kernel[0].

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

If you are unable to test the mainline kernel, for example it will not boot, please add the tag: 'kernel-unable-to-test-upstream'.
Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".

Thanks in advance.

[0] http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.1-rc8-unstable/

[Michael Titke (michael-tiedtke-i)]

> Joseph Salisbury (jsalisbury) wrote 40 minutes ago: #3
>
> Would it be possible for you to test the latest upstream kernel?

I'm sorry but I am not able to test any snapshot builds, upgrades or else. I've got a fixed time frame to get the machine up and running, do some testing, configuration, security audits, bug reports and port my own utilities from Mac OS X to Ubuntu. And I'm lacking the necessary bandwidth, too.

For now /ext3/ works great for me but I had to find out that /mount/ displays "ext4" even though in fstab it's still marked as /ext3/. I can't change the meta information regarding the /root/ file system in the GUID partition table using /gparted/ in a running system but it behaves like ext3 without any problems.

Then again I'm sorry but I think I remember similar performance issues with /ext4/ from about ten years ago? It may even have been that /Celeron/ machine with the OpenBSD sticker on it predating my first iBook.

[Launchpad Janitor (janitor)]

[Expired for linux (Ubuntu) because there has been no activity for 60 days.]