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

Re: Description of the Journaling topology

From: Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>
Date: Thu, 30 Dec 2004 19:03:08 -0800 (PST)

:>     So the basic property of being able to restore within N seconds is
:>     still guarenteeable even without a journal-aware filesystem.
:Yes, this is what I am talking about. So that you can forget about fast 
:recovery of filesystem into a consistend state after a crash - one of 
:the selling points of today's journaled fs.

    As I said it would require that the filesystem be aware of the 
    journal's existance, plus to do 'fast' recovery you would have to record
    changes at the block level rather then at the operations level.
    With a block level implementation the filesystem would either
    have to provide 'known stable' synchronization points every so often
    (which is actually pretty easy to add to a journal-unaware filesystem),
    or you would have to go full-throttle and have the filesystem record
    block level changes transactionally.  But a block level implementation
    is really only good for one thing: fast recovery.  It doesn't solve any
    of the problems that a high level journal solves.  It doesn't help with
    the cache coherency protocol, it doesn't solve any of the clustering 
    issues, it doesn't prevent software-caused filesystem corruption (it just
    duplicates it), it doesn't provide any of the functional separation that
    makes a high level journal so robust, it can't be used for backups
    anywhere near as well (since you would only be able to restore to a
    block device of exactly the same size as the original filesystem), the
    granularity of your ability to restore to a point of time would be 
    fairly restricted (where as with a high level journal the granularity
    is on an operation-by-operation basis), it isn't possible to filter a
    block level implementation (e.g. 'I only want changes made within this
    subdirectory'), because any given filesystem block change might cover
    more then one opration and unrelated changes to one block will effect
    others (like bitmap blocks), it isn't useful for security auditing,
    and so on and so forth.

    Simply put, a block level journal has a very narrow scope of usefullness.
    Pretty much fast-recovery is all you get out of it.  Not to say that
    fast recovery isn't useful, but I am not going to focus on it first.

					Matthew Dillon 

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