Re: Description of the Journaling topology

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:I think referring to Journaling is a bit misleading as these features 
:will not help the traditional case of recovery after power loss on a 
:file system (all buffered data would be lost as it is in memory). It 
:seems to be more of an integration of transactions into the VFS layer, 
:so that the kernel will use a Transaction topology when reading/writting 
:data. I am guessing that the actual file system/remote file system will 
:do any 'journaling' and indicate when transactions are committed etc. 
:How will non-journaling file systems work? Will this inter operate with 
:anything else that is not DragonFlyBSD (if it doesn't it makes remote 
:backup less useful).
:
:Could do all of this from a user application (a lot of distributed file 
:system's work from user land I think)?

    I'm not sure I follow.  The journaling will eventually be used as part
    of the cache coherency mechanism but that isn't how it is being used
    initially.  The shortest description of what our journaling will do
    is simply that it will record every filesystem operation performed to
    a decriptor which might just happen to be a socket.  If the network
    link between the originating machine and the target machine is fast
    enough, the journal we represent a near real-time copy of the originating
    machine's filesystem.

    Filesystems do not have to be aware of this aspect of the journaling
    mechanism.  e.g. for UFS one would still (at least for now) fsck 
    normally after a crash, but one would also be able to rerun portions of
    the journal to recover any data buffered but not written to the filesystem
    at the time of the crash (if the journal's connection to the target
    machine was fast enough to get the data to the target box before the
    machine crashed).

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>