Date: Sun, 8 Jul 2001 21:12:26 +0100 From: David Malone <dwmalone@maths.tcd.ie> To: Dave Uhring <duhring@charter.net> Cc: "Jim C. Nasby" <jim@nasby.net>, freebsd-stable@FreeBSD.ORG, Oliver Fromme <olli@secnetix.de> Subject: Re: JFS Message-ID: <20010708211226.A2595@walton.maths.tcd.ie> In-Reply-To: <000d01c1074e$49d31ba0$0300a8c0@uhring.com>; from duhring@charter.net on Sat, Jul 07, 2001 at 08:35:35PM -0500 References: <200107071638.SAA19610@lurza.secnetix.de> <01070711475500.00362@dave> <3B476285.43347BA1@nasby.net> <000d01c1074e$49d31ba0$0300a8c0@uhring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Jul 07, 2001 at 08:35:35PM -0500, Dave Uhring wrote: > You seem to have missed the critical point of that paper. When the > system goes completely haywire and either crashes or locks up so hard > that a manual reset is required, UFS/softupdates requires a substantial > amount of time to run fsck. Background fsck is now working in -current, which means that when your system boots you don't have to fsck the disk immediately. It seems to work just fine for me so far. > If you have a very large filesystem, you > then have to w....a....i....t until fsck completes. I believe that giving the right options to newfs can significantly reduce fsck times too. There's notes on it in the new tuning man page. > I use "logging" on Solaris and XFS on Linux and have tried reiserfs on > Linux. All are superior to UFS/softupdates when the going gets tough. > Disk access times may or may not be comparable with UFS/softupdates, but > the integrity of my filesystems is more important than raw speed. AFAIK Softupdates shouldn't be any less carefull with your data than journaling, providing the application calls fsync. One advantage might be that data is written to the disk twice, which means if one bit of the disk goes bad you might be able to find it elsewhere. (Mind you, I guess RAID is the right way to do that sort of thing.) I dunno which is harder to impliment right - journaling or softupdates. This may actually be the issue which determines the safety of your data. David. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010708211226.A2595>