Date: Fri, 07 Dec 2007 13:48:12 +0100 From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= <des@des.no> To: Bjorn Gronvall <bg@sics.se> Cc: freebsd-fs@freebsd.org Subject: Re: FSCK doesn't correct file size when INCORRECT BLOCK COUNT is found Message-ID: <86hciuu0vn.fsf@ds4.des.no> In-Reply-To: <20071206175608.594685d9@ibook.sics.se> (Bjorn Gronvall's message of "Thu\, 6 Dec 2007 17\:56\:08 %2B0100") References: <1196788555.47558b4bab0ab@imp.free.fr> <1196953310.47580ede28676@imp.free.fr> <20071206175608.594685d9@ibook.sics.se>
next in thread | previous in thread | raw e-mail | index | archive | help
Bjorn Gronvall <bg@sics.se> writes: > Filesystems in general and UFS with soft updates in particular rely on > disks providing accurate response to writes. When write caching is > enabled the disk will lie and tell the operating system that the write > has completed successfully, in reality the data is only cached in disk > RAM. When the power disappears the data will be gone forever. No. This used to be the case with some cheaper disks which ignored the ATA "flush cache" command to score higher on benchmarks, but I doubt you'll find any disks on the market that still do that (at least from reputable manufacturers). ZFS makes extensive use of the "flush cache" command to ensure file system integrity (and in particular to ensure that the intent log is written to disk so it can be replayed in case of a crash). DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?86hciuu0vn.fsf>