DragonFly BSD
DragonFly bugs List (threaded) for 2009-10
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

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

From: Bill Hacker <wbh@xxxxxxxxxxxxx>
Date: Mon, 26 Oct 2009 23:54:31 +0800

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.



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.


[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]