Date: Wed, 27 Oct 2010 12:18:31 +0200 From: Ivan Voras <ivoras@freebsd.org> To: freebsd-hackers@freebsd.org Subject: Re: fsync(2) manual and hdd write caching Message-ID: <ia8u9l$46j$1@dough.gmane.org> In-Reply-To: <20101027111124.00007450@unknown> References: <20101026213618.GA3013@freebsd.org> <ia7nln$piv$1@dough.gmane.org> <4cc7ea44.ApOaxS8Xr4Sxu%2B0x%perryh@pluto.rain.com> <20101027111124.00007450@unknown>
next in thread | previous in thread | raw e-mail | index | archive | help
On 10/27/10 12:11, Bruce Cran wrote: > On Wed, 27 Oct 2010 02:00:51 -0700 > perryh@pluto.rain.com wrote: > >> Short of mounting synchronously, with the attendant performance >> hit, would it not make sense for fsync(2) to issue ATA_FLUSHCACHE >> or SCSI "SYNCHRONIZE CACHE" after it has finished writing data >> to the drive? Surely the low-level capability to issue those >> commands must already exist, else we would have no way to safely >> prepare for power off. > > mounting synchronously won't help, will it? As I understand it that > just makes sure that data is sent straight to disk and not left in > memory; the data will still be stored in the HDD cache for a > while. Correct. The problem is actually pretty hard - since AFAIK SoftUpdates doesn't have "checkpoints" in the sense that it groups writes and all data "before" can guaranteed to be on-disk, the problem is *when* to issue BIO_FLUSH requests. One possible solution is to simply decide on a heuristic like: "ok, doing BIO_FLUSH all the time will destroy performance, we will only do it for every metadata write". Possibly with a sysctl tunable or per-mount option.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ia8u9l$46j$1>