lucid fsck takes too long

Bug #584050 reported by yeti
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Expired
Undecided
Unassigned

Bug Description

cat proc/version
Linux version 2.6.32-22-generic (buildd@rothera) (gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5) ) #33-Ubuntu SMP Wed Apr 28 13:27:30 UTC 2010

mountall --version
mountall 2.15
Copyright (C) 2010 Canonical Ltd.

This is not bug 571707; mountall 2.15 solved that really long hang-up here.

fsck using knoppix on /dev/sda4 takes less than a second.
Lucid fsck occurring every 20 mounts takes one minute 40 seconds when it occurs.

/dev/sda4 is ext3, a journalled system; if 'clean' it takes less than a second to fsck.
I suspect somehow lucid partition is being marked 'not clean' and is getting the whole nine yards fsck.

This is no _big_ problem, but things are not quite right.
Perhaps a minor additional tweak of mountall is in order.

Revision history for this message
Jeremy Foshee (jeremyfoshee) wrote :

Hi yeti,

Please be sure to confirm this issue exists with the latest development release of Ubuntu. ISO CD images are available from http://cdimage.ubuntu.com/daily-live/current/ . If the issue remains, please run the following command from a Terminal (Applications->Accessories->Terminal). It will automatically gather and attach updated debug information to this report.

apport-collect -p linux 584050

Also, if you could test the latest upstream kernel available that would be great. It will allow additional upstream developers to examine the issue. Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Once you've tested the upstream kernel, please remove the 'needs-upstream-testing' tag. This can be done by clicking on the yellow pencil icon next to the tag located at the bottom of the bug description and deleting the 'needs-upstream-testing' text. Please let us know your results.

Thanks in advance.

    [This is an automated message. Apologies if it has reached you inappropriately; please just reply to this message indicating so.]

tags: added: needs-kernel-logs
tags: added: needs-upstream-testing
tags: added: kj-triage
Changed in linux (Ubuntu):
status: New → Incomplete
Revision history for this message
yeti (utu) wrote :

Thank you for your automated response, Jeremy.

To demonstrate this as your automated message suggests, I think would require two new installs. Since Ubuntu went to Grub2 I hesitate to do anything so major on my dual boot system without a very good reason.

What I've noted I don't know how to demonstrate on a liveCD. It is something that happens on the 'forced fsck' every 20 mounts on an installed system.

If the clues I've given don't suggest something useful regarding a regression I never experienced in the last several years using Ubuntu, then I can wait for a better reason to re-install.

You might want to try using any liveCD of yours on any healthy unmounted Ubuntu system of yours and see what results you get for fsck on a 'clean' ext3 partition. I don't think it's one minute 40 seconds.

Revision history for this message
Jeremy Foshee (jeremyfoshee) wrote :

Hi yeti,
    Thanks for your update. I agree that it would be difficult to reproduce. I am marking this triaged to get a Kernel Team member to take a look at it and see what we can do to look into the problem.

Thanks!

~JFo

Changed in linux (Ubuntu):
status: Incomplete → Triaged
tags: added: kernel-core
Revision history for this message
yeti (utu) wrote :

Jeremy, FYI

Concerning the obligatory fsck every 20 mounts with Lucid:
With the splash screen _off_ , at 30 seconds of black screen the console reports that
the fsck is being done by util-linux-ng 2.17.2; This lasts one minute 40 seconds before continuing to the login phase. No report of found errors on /dev/sda4, the Ubuntu partition.

Revision history for this message
yeti (utu) wrote :

ps.

Bugs #423247 and #454233 may have some bearing on this.

Bug #423247 refers to improper time stamp references.

Bug #454233 refers to an unsuccessful attempt to fsck an ntfs partition.
XP is on another partition of my dual-boot setup.

Revision history for this message
yeti (utu) wrote :

pps

Anyone caring to verify this may find it convenient to hurry-up the process to the next fsck.

If showfsck indicates the max count to be 20, then the command
tune2fs -C 21 /dev/sda4, or whatever the Ubuntu partition is, will make the fsck come up on the very next boot.

FWIW, fsck should only look at drives called-out in /etc/fstab.
In my case, the ntsf partition for XL does not show.

Revision history for this message
yeti (utu) wrote :

I notice two things unique to Lucid in regard to fsck.

1. changing FSCKFIX=no to yes in /etc/default/rcS has _no_ effect.
2. the code in /etc/init/mountall.conf has some bearing on this.

Item 1 appeared a while back in response to earlier impatience with
Debian allowing too frequent fsck of ext3 systems.

Item 2 seems fairly new and related to _mountall_ testing more than
anything else. Maybe an unnecessary artifact?

Revision history for this message
penalvch (penalvch) wrote :

yeti, this bug was reported a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue? If so, could you please test for this with the latest development release of Ubuntu? ISO images are available from http://cdimage.ubuntu.com/daily-live/current/ .

If it remains an issue, could you please run the following command in the development release from a Terminal (Applications->Accessories->Terminal), as it will automatically gather and attach updated debug information to this report:

apport-collect -p linux <replace-with-bug-number>

Also, could you please test the latest upstream kernel available following https://wiki.ubuntu.com/KernelMainlineBuilds ? It will allow additional upstream developers to examine the issue. Please do not test the daily kernel folder, but the one all the way at the bottom. Once you've tested the upstream kernel, please comment on which kernel version specifically you tested. If this bug is fixed in the mainline kernel, please add the following tags:
kernel-fixed-upstream
kernel-fixed-upstream-VERSION-NUMBER

where VERSION-NUMBER is the version number of the kernel you tested. For example:
kernel-fixed-upstream-v3.12-rc2

This can be done by clicking on the yellow circle with a black pencil icon next to the word Tags located at the bottom of the bug description. As well, please remove the tag:
needs-upstream-testing

If the mainline kernel does not fix this bug, please add the following tags:
kernel-bug-exists-upstream
kernel-bug-exists-upstream-VERSION-NUMBER

As well, please remove the tag:
needs-upstream-testing

Once testing of the upstream kernel is complete, please mark this bug's Status as Confirmed. Please let us know your results. Thank you for your understanding.

Changed in linux (Ubuntu):
status: Triaged → Incomplete
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in linux (Ubuntu):
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.