Re: Description of the Journaling topology
: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@backplane.com>
討論串 (同標題文章)
完整討論串 (本文為第 11 之 42 篇)：