Date: Mon, 1 Nov 1999 23:06:03 +0100 (CET) From: Wilko Bulte <wilko@yedi.iaf.nl> To: tlambert@primenet.com (Terry Lambert) Cc: Stephen.Byan@quantum.com, freebsd-fs@FreeBSD.ORG Subject: Re: journaling UFS and LFS Message-ID: <199911012206.XAA25459@yedi.iaf.nl> In-Reply-To: <199911012151.OAA05179@usr02.primenet.com> from Terry Lambert at "Nov 1, 1999 9:51:44 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
As Terry Lambert wrote ... > > >> Softupdates is definitely a viable solution however it does not address > > >> several issues and the license is not a BSD license so it makes me > > >> uncomfortable. > > The license issue is a Whistle thing. Talk to Julian and get him > to pound on Doug Brent, preferrably before December 31st of this year. > > > > >Could you let me know what SoftUpdate does not address? > > >Thank you. > > > > One potential problem with soft updates is that the order of > > creation/deletion/truncation/etc of files is not preserved through a crash > > or power outage, wheras UFS and logged file systems (not logging file > > systems as in LFS; what do you say the kind that maintain a recovery log in > > addition to their regular metadata?) preserve this ordering. I wonder how > > many recovery strategies are broken by soft updates. Anyone have any data? > > This is not strictly true of soft updates, if you have a well > behaved disk drive. > > The problem with the current implementation is that, when you > have uncooperative hardware, you have to sacrifice some of your > performance by disabling write caching. > > Probably, you have not disabled write caching. > > If the drive would notify when the data has truly been committed > to stable storage, as opposed to the write cache, or even if there > were an out of band mechanism to force the drive to flush its write > cache (and eat the stall that would have to be introduced for this > to work), you could get significantly better performance without > risking your data. On SCSI you should be able to use the SYNCHRONISE CACHE cmd to get the data onto the platter. How to prioritise this cmd into the various queues is another matter. (As are less-than-wellbehaved SCSI devices that A. don't implement the cmd or B. implement it wrongly or C. forget all about write caching when hit with a SCSI bus reset or... you get my point) Wilko -- | / o / / _ Arnhem, The Netherlands - Powered by FreeBSD - |/|/ / / /( (_) Bulte WWW : http://www.tcja.nl http://www.freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199911012206.XAA25459>