Comment 11 for bug 1105900

Good evening, Luis Henriques, folks.

Coming back to the Ubuntu 12.04.1 x64 system running kernel 3.2.0-36 which made me open this bug report. (cf. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1105900/comments/0):

Tonight at 19:50 the kernel was updated to K3.2.0-37.

---Synaptic history---
Commit Log for Mon Jan 28 19:50:18 2013

Die folgenden Pakete wurden aktualisiert:
linux-generic (3.2.0.36.43) to 3.2.0.37.44
linux-headers-generic (3.2.0.36.43) to 3.2.0.37.44
linux-image-generic (3.2.0.36.43) to 3.2.0.37.44
linux-libc-dev (3.2.0-36.57) to 3.2.0-37.58

Die folgenden Pakete wurden installiert:
linux-headers-3.2.0-37 (3.2.0-37.58)
linux-headers-3.2.0-37-generic (3.2.0-37.58)
linux-image-3.2.0-37-generic (3.2.0-37.58)
---Synaptic history end---

The machine was rebooted to load the updated kernel.

---lsb_release -rd;uname -a output ---
$ lsb_release -rd;uname -a
Description: Ubuntu 12.04.1 LTS
Release: 12.04
Linux Voyager 3.2.0-37-generic #58-Ubuntu SMP Thu Jan 24 15:28:10 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
---lsb_release -rd;uname -a end---

---grep "EXT4-fs syslog" after first boot of K3.2.0-37---
syslog:Jan 28 20:00:57 Voyager kernel: [ 3.919628] EXT4-fs (sda5): orphan cleanup on readonly fs
syslog:Jan 28 20:00:57 Voyager kernel: [ 3.937261] EXT4-fs (sda5): ext4_orphan_cleanup: deleting unreferenced inode 2895492
syslog:Jan 28 20:00:57 Voyager kernel: [ 3.937489] EXT4-fs (sda5): ext4_orphan_cleanup: deleting unreferenced inode 2895491
syslog:Jan 28 20:00:57 Voyager kernel: [ 3.937500] EXT4-fs (sda5): ext4_orphan_cleanup: deleting unreferenced inode 2895490
syslog:Jan 28 20:00:57 Voyager kernel: [ 3.937517] EXT4-fs (sda5): ext4_orphan_cleanup: deleting unreferenced inode 2895489
syslog:Jan 28 20:00:57 Voyager kernel: [ 3.937525] EXT4-fs (sda5): ext4_orphan_cleanup: deleting unreferenced inode 2895488
syslog:Jan 28 20:00:57 Voyager kernel: [ 3.937539] EXT4-fs (sda5): 5 orphan inodes deleted
syslog:Jan 28 20:00:57 Voyager kernel: [ 3.937541] EXT4-fs (sda5): recovery complete
syslog:Jan 28 20:00:57 Voyager kernel: [ 3.969702] EXT4-fs (sda5): mounted filesystem with ordered data mode. Opts: (null)
syslog:Jan 28 20:00:57 Voyager kernel: [ 21.609817] EXT4-fs (sda5): re-mounted. Opts: errors=remount-ro
---grep "EXT4-fs syslog" after first boot of K3.2.0-37 end---

This was to be expected because K3.2.0-36 had left behind open file handles on shutdown.

BUT:

---grep "EXT4-fs syslog" after second boot of K3.2.0-37---
syslog:Jan 28 20:12:07 Voyager kernel: [ 4.130957] EXT4-fs (sda5): mounted filesystem with ordered data mode. Opts: (null)
syslog:Jan 28 20:12:07 Voyager kernel: [ 21.736968] EXT4-fs (sda5): re-mounted. Opts: errors=remount-ro
---grep "EXT4-fs syslog" after second boot of K3.2.0-37 end---

Great, no more cleanup needed on reboot. Yet, uptime had been only few minutes. So let us try again a little later.

---grep "EXT4-fs syslog" after third boot of K3.2.0-37---
syslog:Jan 28 22:35:27 Voyager kernel: [ 3.756446] EXT4-fs (sda5): mounted filesystem with ordered data mode. Opts: (null)
syslog:Jan 28 22:35:27 Voyager kernel: [ 21.520713] EXT4-fs (sda5): re-mounted. Opts: errors=remount-ro
---grep "EXT4-fs syslog" after third boot of K3.2.0-37 end---

Great, again no more cleanup needed on reboot after an uptime of about 2h 23 mins.

Prelimary conclusion:
-----------------------------
There is good reason to be optimistic that K3.2.0-37 on Ubuntu 12.04.1 x64 has solved the problem introduced by K3.2.0-36.
Yet, two reboots are not sufficient to be sure.
Therefore, I will use this system in a normal way which implies that it will not be rebooted more than once a day after having been up for several hours.
I will report back after a few more days. Let us say by the end of the week.

Cheers,
Karl