Date: Thu, 31 Jan 2002 16:35:50 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Rahul Siddharthan <rsidd@online.fr> Cc: hackers@freebsd.org Subject: Re: Again Softupdates on 4.5 Message-ID: <3C59E2E6.6C19BED3@mindspring.com> References: <20020131165803.C6390@lpt.ens.fr>
next in thread | previous in thread | raw e-mail | index | archive | help
Rahul Siddharthan wrote: > After that I turned write caching off. I had one more panic, but no > disasters -- the automatic fsck worked. Maybe it's just me but I > don't really notice a slowing down with write caching off (softupdates > is still on). Write caching permits the disk to reorder writes, as it sees fit. Forcing a disk cache cycle at a barrier point when doing the graph dependency resolution fixes the problem (e.g. at the end of each soft updates update daemon write cycle, which can be done by adding a "barrier" pseudo-op into the write queue list -- the "barrier" isn't passed until the disk acknowledges that the cached writes have been fully committed). Effectively, this is the same thing as the degenerate case where the writes are delayed and ordered (the USL/Novell DOW patent), in the case that tagged queueing isn't available on the disk. This makes it risky (it's basically the same thing that ReiserFS does, which I firmly believe is covered by the patent; I examined the technology in 1994, during the patent filing, at Novell/USG). This won't work for a lot of "modern" ATA disks, because they lie when you tell them to write their cache (I guess dishonesty makes them "more modern" than hardware that tells the truth, and does what you tell it to do). There's a "known rogues" list of ATA write flush liars, but I don't have it. I think Soren mentioned it one time. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C59E2E6.6C19BED3>