On Mar 25,  3:20pm, Thor Lancelot Simon wrote:
} Subject: Re: softdep?
} On Thu, Mar 25, 1999 at 12:48:13PM -0700, Justin T. Gibbs wrote:

} > >LFS will at least let you boot your system faster,
} > 
} > Soft updates gives you this as well since all you need to perhaps
} > add a few blocks back into the free block bitmaps and this can be
} > done in the background at boot or at some regular maintenance
} > interval.
} 
} And the recovery tool is where?

All this stuff is still a work in progress ..

} I don't see many people not running fsck
} at boot on their FFS filesystems, and in fact the McKusick code includes
} patches to fsck to detect and correct new metadata problems which can arise
} specifically _because_ of the soft update code, as did the original Ganger
} pseudocode.

My understanding is that the "metadata problems" are pretty harmless
and should not prevent the filesystem from being usable after a crash
and reboot.  The only downside to not repairing them would be some
orphaned resources.

That said, I'm pretty conservative and still force fsck to check filesystems
with the clean flag set.

} > Because of these features, the value of LFS over FFS is marginalized.
} 
} Maybe.  When I run the McKusick soft update code, I still see an awful lot
} of synchronous writes

This hasn't been a problem in my experience.  On our news server, which
is running a five month old version of the soft update code:

news: {64} uptime
 3:31PM  up 36 days, 15:38, 1 user, load averages: 0.47, 0.35, 0.33
news: {65} /sbin/mount
[ snip ]
/dev/da2s1e on /news/spool (local, noatime, nodev, noexec, soft-updates, writes: sync 28075 async 44473260)

I am very pleased with the performance of soft updates on this server.

} Unless you're
} using a disk that's old enough to have physical geometry FFS can optimize
} for -- and if you're not, all that gunk in FFS is just useless overhead.

I wouldn't mind seeing this ripped out ...