Date: Sat, 12 Apr 2003 23:54:25 -0400 From: Bill Vermillion <bv@wjv.com> To: freebsd-fs@freebsd.org Subject: Re: PATCH: Forcible delaying of UFS (soft)updates Message-ID: <20030413035425.GA681@wjv.com> In-Reply-To: <20030412231802.GB85377@woodstock.nethamilton.net> References: <C1398952884B984C8AB1519CEAC66F940A18DF@OLYMPIC.AD.HartBrothers.Com> <20030412172455.GA85377@woodstock.nethamilton.net> <20030412185346.GB52650@wjv.com> <20030412231802.GB85377@woodstock.nethamilton.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Throwing caution to the wind and speaking without thinking about what was being said on Sat, Apr 12, 2003 at 18:18 , Jon Hamilton blurted this: > Bill Vermillion <bv@wjv.com>, said on Sat Apr 12, 2003 [02:53:46 PM]: > } In the last exciting episode of the Jon Hamilton saga > } on Sat, Apr 12, 2003 at 12:24 , Jon Hamilton as heard to say: > } > Dave Hart <davehart@davehart.com>, said on Sat Apr 12, 2003 [04:58:13 PM]: > } > } Marko Zec said: > } > [...] > } > } > If the disk would start spinning every now and than, > } > } > the whole patch would than become pointless... > } > } > } As I feared. > } > } > [...] the fact that the modified fsync() just returns > } > } > without doing anything useful doesn't mean the data will be > } > } > lost - it will simply be delayed until the next coalesced > } > } > updating occurs. > } > } Unless, of course, your system or power happens to fail. > } > } Imagine you have a database program keeping track of banking > } > } transactions. This program uses fsync() to ensure its > } > } transaction logs are committed to reliable storage before > } > } indicating the transaction is completed. Suppose the moment > } > } after I withdraw $500 from an ATM, the operating system or > } > } hardware fails at the bank. > } > Right. So in such a situation, the admin for that system would not > } > enable this optional behavior. There probably aren't too many cases > } > where mission critical financial transaction systems run on a laptop > } > on which the desire is maximal battery life, which is the case from > } > which this whole patch/discussion derives. It's a conscious tradeoff. > } I think 'the admin could enable this optional behaviour' is the > } wrong approach. > } I think it should be for laptops the admin could >disable< the > } feature. By default make everyting as robust and failsafe as > } possible. > I agree, and that's what I said. Unfortunately, I wasn't overly clear > about it. The optional behavior would be the _enabling_ of the patch > behavior. I feel better about it already :-) Thanks for the clarification. Bill -- Bill Vermillion - bv @ wjv . com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030413035425.GA681>