Re: HAMMER: you can mount_hammer a UFS that was a hammer fs before

[Bill Hacker <wbh@xxxxxxxxxxxxx>]

Jan Lentfer wrote:
> Bill Hacker schrieb:
> > Jan Lentfer wrote:
> > > If a partition contains a hammer fs and you newfs it to a UFS you can 
> > > afterwards still mount it as hammer fs.
> > > You can even still run hammer info and write data on the partition 
> > > (tried with dd).
> >
> > ?  'dd' does not know or care anything about a fs.
> >
> > What happens if you not only 'newfs' to UFS, but actually *write* to 
> > it AS a r/w UFS mount? (e.g. - not with 'dd').
> >
> > If hammer fs can 100% recover from that, there is witchcraft afoot....
>
>
> Actuall I tried the other way and it worked: You can write data on the 
> mount_hammer'd UFS with if=/dev/zero of=/mnt/ZEROS (which cares about 
> the fs), umount it and mount (UFS) it. Then you will not the the created 
> file with ls. unmount again, mount_hammer, ls and ... surprise ... data 
> will be there  again. That is nice, isn't it.
>
> Cheers
>
> Jan

hammer fs (and others before it) have a great deal of ability to prevent or 
detect unwanted alterations when running 'normally'.

Many fs have 'some' ability to detect malicious/experimental/accidental 
*offline* alterations. IOW - they tend to 'trust' a dirty-bit flag, and take no 
action until asked - THEN they may be able to find the damage.

'Some' fs - hammer among them, have at least limited ability to correct, 
restore, or at least sequester (lost+found) alterations when detected.

But... unless the 'dirty bit' flag calls for a chkdsk, scandisk, fsck or 
equivalent, 'offline' originated damage will ordinarily go undetected until the 
next maintenance run, OR at least access is attempted to the altered/damaged 
area or file.

IOW - there is nothing that forces a surreptitous / offline alteration to post a 
 'Kilroy was here' message at the front door.

That has been a fact of life from the time documents were stored on vellum or 
papyrus. Applying ECC or checksums is all well and good - but something has to 
cause them to be queried. On large enough media, that is usually too costly do 
gratuitously do at mount-time. IBM chkdsk on hpfs-386 had astonishgly good 
recovery capability for its day. But even the least-extensive of its progressive 
levels could add 15 wall-clock minutes to boot time with a mere 2GB to scan.

End result? A fast and robust fs, but totally impractical for large media.

UFS is better: For my (n)atacontrol RAID1, I usually set 'fsck -y' and stand the 
pain of a veeeeery looong fsck on large HDD - knowing I'll not get recovery - 
only damage-limitation and awareness of a problem.

hammer fs can offer more.

But is has no 'angel' watching from outside the window to tell it you are 
messing with it offline.

So - whatever else, you are not onto a 'bug' here - just a fact of life.

Now - if hammer were *asked* to see if integrity had been compromised - either 
by trying to read from that area, or by invoking any of the several 
maintenance/admin runs, AND THEN failed to notice what had been done - that 
would be another situation entirely.

Bill