Futures - HAMMER comparison testing?
Bill Hacker
wbh at conducive.org
Thu Jan 17 17:59:52 PST 2008
Matthew Dillon wrote:
:Sorry to hijack this thread.
Not to worry!
It was *intended* to be 'hijacked'. Welcome!
Just wanna mention a little write down of
:mine about HammerFS features (and sometimes comparing it with ZFS):
:
:http://www.ntecs.de/blog/articles/2008/01/17/zfs-vs-hammerfs
:
:I can't await to try it out in real!
:
:Regards,
:
: Michael
Nice. There are a few factual mistakes but nothing major. ZFS is
reliable on a 386 system, you just have to limit its memory consumption
with (I think) a sysctl. HAMMER's resource use is still far lower,
though. There are still reports of total corruption for ZFS on FreeBSD
but the issue doesn't sound insurmountable.
Not just on FreeBSD. There are some 'bad news' ZFS stories on the
Solaris-on-UltraSPARC lists as well.
But - so far- more seem to be 'tuning' issues than structural.
HAMMER doesn't journal. Theoretically by carefully ordering
certain I/O operations it will not have to journal.
As with 'softupdates' the net result - reduced risk of damage - is more
important than the technique used to deliver it.
More importantly,
HAMMER can 'recover', as in regenerate, the contents of a cluster on
the fly by scanning the records in that cluster and then rebuilding
the B-Tree and allocation radix trees from scratch. As long as
recognizable records are present, it should be possible to recover a
considerable amount of information even after the disk gets scratched.
Again - so long as it can be trusted to actually *deliver the goods*,
the method is 'don't care' to the end-user.
The historical nature and backup sections are correct, minus your
journaling comment. Basically you make backups by working from an
as-of access. You don't even have to make an as-of mount, there's
an @@timestamp extension that allows you to access the filesystem
as-of any time. So, e.g. you can do things like:
'diff /mnt /mnt/@@0x<timestamp>'.
More information about the Users
mailing list