Date: Sat, 12 Apr 2003 12:24:55 -0500 From: Jon Hamilton <hamilton@pobox.com> To: Dave Hart <davehart@davehart.com> Cc: freebsd-stable@freebsd.org Subject: Re: PATCH: Forcible delaying of UFS (soft)updates Message-ID: <20030412172455.GA85377@woodstock.nethamilton.net> In-Reply-To: <C1398952884B984C8AB1519CEAC66F940A18DF@OLYMPIC.AD.HartBrothers.Com> References: <C1398952884B984C8AB1519CEAC66F940A18DF@OLYMPIC.AD.HartBrothers.Com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. -- Jon Hamilton hamilton@pobox.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030412172455.GA85377>