DragonFly BSD
DragonFly kernel List (threaded) for 2005-03
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: Journaling layer update - any really good programmer want to start working on the userland journal scanning utility ? You need to have a LOT of time available!

From: Bill Hacker <wbh@xxxxxxxxxxxxx>
Date: Sat, 05 Mar 2005 06:43:54 +0800

Matthew Dillon wrote:

:I have a question about this. How far can the UNDO system go? Will it
:be some kind of redo-log (think VxFS here) or will it allow arbitrary
:undo levels? Maybe it sounds crazy, but you could have 'unlimited' undo
:where unlimited amounts to available free disk space. It complicates
:the free block management a bit, but it's certainly doable. Basically
:the journal code should have an undo bitmap. It can allocate any free
:data block to store undo information. As soon as a datablock is needed
:by the sytem the oldest undo datablock gets used to store data. The
:filesystem doesn't need to know about it, just the journaling code,
:although balloc now needs to go through the journal code to make sure
:the undo blocks bitmap gets updated as well. This bitmap could live
:anywhere in the disk.

    The way the UNDO works is that the journal is made 'reversable', meaning
    that you can run the journal forwards and execute the related filesystem
    operations in order to 'track' a filesystem, or you can run the journal
    backwards in order to reverse-time-index a filesystem.  So what you get
    is an infinitely fine-grained undo capability.

    So, for example, lets say someone does a file truncation.  A forward-only
    journal would store this:

    truncate {
	file path / vnode id
	at offset BLAH

A reversable journal would store this:

truncate {
file path / vnode id
at offset BLAH
extend to offset original_blah
write { (the data that was destroyed)
at offset
write {
at offset

    If someone were to do a write() which overwrites prior data, the UNDO
    section would have to contain the original data.

If you were to remove a 4GB file the journal would have to store 4GB worth of data to UNDO that operation.

But what you get is a complete audit trail, the ability to run the journal forwards or backwards when reconstructing a filesystem or
database, the ability to not only undelete a file but also to restore
it (or an entire subhierarchy) as-of a particular date, the ability to
figure out exactly how a security event might have occured, and a host of
other capabilities.

The UNDO capability will be optional, of course, but I see a lot of
people, including myself, using it. All of that disk space has to be good for something eh?


I just finished running a buildworld test with /usr/obj journaled (without UNDO since it isn't done yet). The buildworld only took 10
seconds longer to run! The journal generated from /usr/obj was about
785 MB uncompressed, and 231 MB compressed. Of course, nobody would
want to journal /usr/obj in real life, but it's a good test!

Matthew Dillon <dillon@xxxxxxxxxxxxx>

:Sounds very well thought out, Matt. Definitely worth a look. I'll try
:to be in IRC during the weekend so maybe we can come up with something.
:-- :Miguel Mendez <flynn@xxxxxxxxxxxxxxxxxx>

This is sounds more like playback' than journaling..

starting to sound similar to a VAX editing playback buffer or
hpfs-386 fs 'feature', even.

hpfs is NOT a journaled fs, but successive runs of the deeper levels of
chdsk would progressively recover deeper and deeper archeological strata.

The problem with hpfs was that it took 'too d**n long' to do even a light-once-over
on a mount that was marked dirty - even in a 1 GB partition.... (fast SCSI too)

Chkdsk hpfs on anything over 4GB, at level '2' was a ticket to an old-age home.
By the time the data had been recovered, you had forgotten why it mattered.

Hence JFS, beloved of Warpenvolk und AIXen.

JFS never takes first place in run-offs against other 'optimized for...' fs,
but it is well-balanced enough to always be in the top few.

It doesn't really preserve much at all of what was 'in-process'.
It just lets you know that the *other* 99.999% of the disk is still OK.
Beats Coroner's Tool Kit all hollow....

It seems to me that audit-trail / undo pitches the journaling-advantage baby
right out with the bathwater.

Performance may be perfectly reasonable when sane undo depth is set.

But some fool will set it to an outrageous number, run tests, and publish
in {other OS}-Journal/World how poorly it compares with {some other fs}, and
the damage will be enduring.

Can the number of undo's above some reasonable number (1?, 2?) be made to
require an intentional compile-time flag setting?

IMNSHO, good-quality hardware RAID, set write-through, not write-back, and
mounted sync, not softupdates, are needed *anyway* if the data is important.
And you then rsync that off-site...

No amount of same-media, same-spindle fallback is worth much without an electron
microscope, cleanroom, US$100,000 to cover the labor costs...
and a guarantee from on-high that the whole facility will neither be burgled nor go up in smoke.

Disks are magically reliable per unit cost these days. They do still die, get stolen,
zapped, dropped, and - more often - get newfs'ed. rm -o or srm'ed by accident....

Better to distribute the fs over the wire - inherent disaster recovery - than make
it too complex locally. Look at ssa and fc-al. Hardware solutions of long-standing.

Firewire-2, USB-2 and GigE with IP NAS can bring that to us less-affluent folks too.....


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