consistent file system inconsistencies (tried replacing drive)
Scott Charron
shewless at unleashed-web.org
Fri Oct 15 21:19:24 UTC 2010
> 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.
More information about the freebsd-fs
mailing list