FSCK doesn't correct file size when INCORRECT BLOCK COUNT is found

Bjorn Gronvall 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:

Hi Dag-Erling,

> 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.

Cheers,
/b


--
  _     _                                           ,_______________.
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 mailing list