Re: Description of the Journaling topology
:That's only true if the journal is written to persistent storage on the
:receiving end. How will you guarantee that the journal will be in synch
:with the actual file system--will operations slow down until the journal
:can be sent/acknowledged or will you allow large windows of buffered
:data to accumulate before the receiving end acknowledges them (in which
:case the journal won't be very useful for crash recovery or coherency)?
:
:Isn't what you want a distributed file system? If not, why not?
I'm not sure what you are asking here. There is always a buffering
delay imposed somewhere. Always. You can't eliminate it. The only
effect this delay has on the application is whether the application
requires acknowledgement of a commit to hard storage before proceeding
or whether it only requires a serialization guarentee during crash
recovery.
Most applications really only care about this: They do operation A
and then do operation B, and if a crash occurs B is only restored if
A can also be restored.
Even database applications would prefer to allow commits to be pipelined
all the way until they intend to export the results outside of the
transactional environment. At that point and *ONLY* at that point
such applications would want to wait until the data is fully committed
such that crash recovery guarentees restoration. This doesn't mean
that you can't have buffering, only that what buffering you do have
will impose certain latencies at that point in time.
The buffering only effects those latencies and only at certain points.
Latency cannot be avoided, and the amount of buffering is not necessarily
responsible for latency. e.g. if you are running over a fast network
the buffering latency could still be in the < 1ms range.
Arguably filesystems are not transactional in nature, at least not
normally. But they don't really have to be ... a journal can still
guarentee serialization of events during crash recovery no matter
how much buffering is used.
-Matt
Matthew Dillon
<dillon@backplane.com>
討論串 (同標題文章)
完整討論串 (本文為第 20 之 42 篇)：