UFS2 fsck Question (semantics of -p)

[Chuck Swiger]

Can Sar wrote:
[ ... ]
> Would you consider it an error if the -p option does not fix 
> inconsistencies caused by a simple power failure, without any hardware 
> or software corruption?

You're asking an interesting question, but the issue of data integrity depends 
not only on the software which comprises the OS, but also on the hardware 
being used.

In particular, the system depends upon the hard drives to reliably report when 
data being written actually has been; SCSI drives, using tagged command 
queuing, especially in conjunction with a battery-backup which ensures the 
drive stays up long enough to flush it's write cache even if system power is 
removed, will tend to fare pretty well.

IDE drives, by contrast, have a bad habit of lying about whether data has 
actually been written to the disk itself rather than simply making it to the 
write cache on the drive.  (Such drives ignore the ATA "FLUSH CACHE" command, 
specificly.)

In other words, showing that a filesystem can become inconsistent in a fashion 
that "fsck -p" cannot correct is interesting and a concern regardless of the 
circumstances, but showing it in cases where you are using battery-backed 
drives and/or SCSI rather than IDE is a lot more meaningful.  If you are using 
IDE devices, your testing will be more meaningful if you disable the IDE 
write-cache entirely.  Also, you should put your results somewhere, perhaps on 
a webpage with links to the filesystem images and a complete dmesg so that the 
OS version and hardware being used is well-documented.

-- 
-Chuck