consistent file system inconsistencies (tried replacing drive)

[Scott Charron]

> This problem was fixed some time ago, i.e. now the freeing
> of disk space is not delayed if there is no free space left
> on the file system.  But the default of not enabling soft-
> updates on the root partition was kept.  Normally it's
> not very important because there aren't many files written
> to on the root file system during normal operation.  Unless
> you have /tmp or similar things included on your root file
> system.  BTW, you also might want to disable atime-updates
> on the root-file system (mount option "noatime"), unless
> you have a reason why you need them.

I will disable atime-updates

>
>  > Also I was under the impression soft-updates would actually require
>  > a little more disk access time and thus make the problem slightly
>  > worse.
>
> No, soft-updates doesn't require more disk access time in
> general.  It caches and re-orders meta data updates, so it
> can even save disk access time.  But the important thing
> is that soft-updates re-orders the meta data updates in a
> way that guarantees that it is in a consistent state at
> any time (provided that the disk's firware cooperates
> correctly).  This means that there won't be _unexpected_
> inconsistencies after a crash, and fsck will be able to
> run without user-intervention.  (NB:  If you want to avoid
> fsck completely, you will have to use journalling, or go
> to a ZFS-only system without any UFS file systems.)
>

Maybe I should just go to ZFS... it's fully supported now even for
root right? Will that be more robust against power outages??

> If you still get unexpected inconsistencies even though
> you use soft-updates everywhere, then something else must
> be wrong.  Maybe your hard disk doesn't play along nicely.
> The usual recommendation is to disable the write-cache
> on hard disks.  This will make your system slower, though.

Remember I'm using a USB stick here :)


> If you see filesystem problems on your non-root filesystem as well, e.g.
> ones with SU (soft-updates) applied, I would recommend setting
> background_fsck="no" in your /etc/rc.conf.  There are some old threads
> documenting how background filesystem checks don't always fix all
> problems before the system starts actually using the filesystem.  There
> were reports of people finding that manual fsck would detect issues that
> background fsck wouldn't fix.  YMMV.

Is this recommended? Should I schedule regular manual fscks?

Thank you.