Date: Mon, 1 Nov 1999 21:51:44 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: Stephen.Byan@quantum.com (Stephen Byan) Cc: freebsd-fs@FreeBSD.ORG Subject: Re: journaling UFS and LFS Message-ID: <199911012151.OAA05179@usr02.primenet.com> In-Reply-To: <8133266FE373D11190CD00805FA768BF02EE9DD7@shrcmsg1.tdh.qntm.com> from "Stephen Byan" at Nov 1, 99 07:04:24 am
next in thread | previous in thread | raw e-mail | index | archive | help
> >> 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. The main recovery strategy that soft updates allows is that, after a crash, the file system state is consistant, with the exception of unallocated blocks showing as allocated in the unflushed-at-the-time-of-the-crash cylinder group bitmaps. Technically, you could lock access to particular cylinder groups as you were fixing up their bitmaps, and effectively do your fsck in the background. One real problem that remains unaddressed in this case, however, is the chicken-and-egg problem. That is, there is no way to distinguigh a power failure or an FS-unrelated panic from an FS-related panic, such as a real disk hardware or buffer cache corrupting failure -- data non-corrupting vs. data corrupting crashes. Without this information, it is unsafe to assume that the crash was an uncorrupting crash, and do the abbrevated fsck. Adding this information would require adding a new bit into the super block, and being willing to write the superblock back in the event of a panic. You would probably have to add a flags parameter to the front of the panic() function in order to tell it what kind of crash was happening; this would be a hell of a lot safer than, for example, a global variable. Another thing that could mitigate this, at least on relatively quiescent systems (e.g. it'd work for power failures in the middle of the night, but wouldn't work for systems with disk writes going on) would be "soft read-only". This would flush all writes, and then if no new writes came in for "a while", you would set a flag on the in code FS structure that you were marking it "soft read-only", and then write out the superblock marking it clean. Subsequent writes would be permitted, but only when the "soft read-only" bit was cleared, after remarking the super block dirty again. We actually implemented both soft updates and soft read-only in our port of FFS to Windows 95, at Artisoft. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. 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?199911012151.OAA05179>