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