FSCK doesn't correct file size when INCORRECT BLOCK COUNT is
bg at sics.se
Fri Dec 7 05:34:18 PST 2007
On Fri, 07 Dec 2007 13:48:12 +0100
Dag-Erling Smørgrav <des at des.no> wrote:
> Bjorn Gronvall <bg at 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).
Agreed, but the software must also be written to actually make use of
the more recent "flush cache" feature. I know that the GEOM journal
can make use of this feature but does UFS with soft updates use it?
> 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).
ZFS is a more recent beast than UFS and was probably designed with the
"flush cache" feature in mind right from the very beginning.
_ _ ,_______________.
Bjorn Gronvall (Björn Grönvall) /_______________/|
Swedish Institute of Computer Science | ||
PO Box 1263, S-164 29 Kista, Sweden | Schroedingers ||
Email: bg at sics.se, Phone +46 -8 633 15 25 | Cat |/
Cellular +46 -70 768 06 35, Fax +46 -8 751 72 30 '---------------'
More information about the freebsd-fs