[Pkg-sysvinit-devel] Bug#568251: Bug#568251: Bug#568251: Please support fsck on shutdown

[Henrique de Moraes Holschuh]

On Wed, 17 Feb 2010, Goswin von Brederlow wrote:
> > With some testing, maybe we can fsck the root on shutdown *when* we succeed
> > at remounting it read-only (but we have to make sure the behaviour, should
> 
> Do we ever fail to remount RO?

Yes.  The kernel can force remount read-only, but userspace is limited to a
much nicer remount-ro, which fails if there are open unlinked files, open
read-write files, etc.

> If remounting RO isn't enough one could load a ramdisk and pivot_root to
> that for the final fsck. That would involve a lot more work though.

I'd say pivot_root is not worth the trouble.

> > fsck find any errors, will be sane.  And that does mean not changing a power
> > off into a reboot, etc).  For time-based triggers, the only fix I can think
> > of is to disable them in the filesystem itself.
> 
> No. If it finds any errors then it must not flag the filesystem as
> checked and power off. Then on boot it will do the normal check and
> prompt for the root password. This is ment so that one can type "halt"
> and still walk away with the ensurance that the system will power off on
> its own.

That means fsck -n, which might well require white-listing to be safe.  Not
a problem, as long as it is done properly.

> > Note that I am not against a partial fix at all, send the patches in :-)
> > But it would be nice if we would change the installer and mkfs defaults to
> > avoid enabling any time-based triggers by default.
> 
> I don't think time-based triggers are a waste. The bits on the medium
> degrade over time and the errors build up till the ECC can't correct
> them anymore. By reading the metadata every now and then you give the
> drive a chance to detect degraded blocks and rewrite them before the
> errors become uncorrectable. You also detect when blocks do become
> uncorrectable.

Yes, but the right way to do that is to do it on the entire device, and do
it at least weekly.

> The perfect solution would be to do online fsck. But till then time and
> count based triggers are the safest way.

Actually, IMO it is pretty weak a solution in these days of SMART firmwares
with short, long and offline test modes.  But that's beside the point.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh