Automatic fsck leaves partition inaccessible without any notification.

[jocko]

Binary package hint: e2fsprogs

I don't know if this is the correct package to file this bug against, but here it is:
In karmic, when an automatic fsck is started on a non-system partition during boot, the system continues the boot process as it should while the fsck is run in the background. This is an improvement over the earlier behaviour (that the entire boot process was paused while waiting for fsck to finish).
My problem is that as the fsck process continues for several minutes after the boot has finished, the partition remains unmounted (and unmountable) without any notification to the user why this happens. The only way to know what's going on is to specifically check in the system monitor, top, ps, etc. if e2fsck is running.
Once the fsck is done, the partition gets mounted automatically as it should, so that's not the problem.

Shouldn't the user be notified why the partition is inaccessible?
Is it possible to get a notification (after login) saying something like:
"A file system integrity check on the device /dev/sdb2 is running in the background. The disk will be accessible when this is ready"
Even better if there would also be a progress bar or an estimated time plus the option to cancel it (and reschedule it to the next boot).

lsb_release -rd
Description: Ubuntu karmic (development branch)
Release: 9.10

apt-cache policy e2fsprogs
e2fsprogs:
  Installerad: 1.41.9-1ubuntu1
  Kandidat: 1.41.9-1ubuntu1
  Versionstabell:
 *** 1.41.9-1ubuntu1 0
        500 http://archive.ubuntu.com karmic/main Packages
        100 /var/lib/dpkg/status

[Scott James Remnant (Canonical) (canonical-scott)]

Probably, but this is not an e2fsprogs issue

[jocko (jomnal00)]

Ok, but where does the issue belong?
The problem is the behaviour of fsck, which is part of e2fsprogs, which is why I filed it against e2fsprogs.
I realize there is nothing wrong in the e2fsprogs package, but there is something wrong with the communication between the user and e2fsprogs, which needs some kind of solution before karmic is released.
Do you have a better idea of where this bug belongs?

[Theodore Ts'o (tytso)]

Point the first, fsck is now being provided by util-linux-ng. Point the second, it's not the behaviour of fsck which is at issue, but the init scripts which are running fsck. Traditionally, Linux systems run fsck twice. Once to check the root file system, and a second time to check the the non-root file systems, and until fsck finished checking all of the non-root file systems, the boot scripts would not continue until all of the non-root file systems were finished being checked.

The init scripts in Karmic are apparently doing something else; specifically, they are running fsck's in three different passes. Once for the root file system, once for the system partitions, and once (in the background) for non-system partitions. The details of how this is getting done, I don't know, because it's being done outside of e2fsprogs, but in the init scripts.

What I would hope is true is:

1) Which partitions are considered "system partitions" and which are not is configurable; it may very well be that for a particular web server, the partition containing /www must be checked before the apache daemons are started up, so /www should be considered a system partition.

2) As much as possible, the non-system file systems are being checked in parallel, if the partitions are located on different spindles so checks can happen as quickly as possible.

As far as whether the user has the authority to skip the file system consistency check of a particular partition, that should be a policy decision set by the system administrator. In some cases, the system administrator may not want a random user to be able to cause a file system consistency check to be skipped. It may also be a good idea to distinguish between the case where the file system is flagged as having errors, and so the file system check is highly advisable in order to prevent data loss, versus a periodic check done because the file system hasn't been checked in a while.

These are all policy questions above e2fsprogs, though. And I suspect some of these may be considered wishlist items as opposed to high priority bugs.

[jocko (jomnal00)]

Thanks Theodore for the explanation, and thanks Niels for updating the package hint from e2fsprogs to ubuntu.

What I suggest is:
1. The user should get notified that a fsck is going on, and that the partition will not be available until the check finishes. I consider this as a bug and not a simple wishlist item, as a user that is not aware of this behaviour may think that he/she has lost data or have some other serious problem. I have no idea how this could be implemented, but I guess it should be possible to somehow pass a message through libnotify (if that is what gives the notifications in the gnome-panel notification tray and it's kde/xfce counterparts).
2. If possible, give a progress indicator that shows the progress of fsck (this would be a wishlist item, but one that would be even better than just giving a simple text notification).
3. Have the option to cancel and reschedule the disk check. I suggest this only because it is possible to do so during the boot-time checks in jaunty, and there may be users that really want this option. This is a wishlist item that I don't see as important, and of course if this would be implemented this option should only be given to members of the admin group and it should ask for the password.

[IanW (launchpad-washuu)]

This caught me too today, thought I'd lost 2TB of stuff!

I agree that some kind of notification should be given via libnotify.

[frinkazoid (frinkazoid)]

Had this happen to me too. A notification would be handy, as I panicked and and rebooted twice before seeing the fsck processes running in background.

Also, does anyone have a clue about how to check the progress of these disk checks ? I have a few drives with a lot of small files on them; and they normally take quite a long time; so a progress indication would be nice