Re: Description of the Journaling topology

["Martin P. Hellwig" <mhellwig@xxxxxxxxx>]

Matthew Dillon wrote:
<cut>
>     Our journaling layer is designed to address these issues.  Providing a
>     high level filesystem operations change stream off-site is far more
>     robust then providing a block device level change stream.  Being able
>     to go off-site in real-time to a secure (or more secure) machine can't
>     be beat.  Being able to rewind the journal to any point in time, 
>     infinitely fine-grained, gives security managers and sysops and even
>     users an incredibly powerful tool for deconstructing security events
>     (e.g. log file erasures), recovering lost data, and so on and so forth. 
>     These are very desireable traits, yah?  

As a System Administrator I must say that this makes me pretty happy and 
I mean <throw other technology out if I can have this>-happy, one of the 
problems is see in my line of job is that I have such amount of data 
that backup is not feasible anymore, what means the cost of the backup 
is higher then the gain that you could recover data after an incident.
A friend of my works at a shop where the SA's have the problem that in 
their environment data production is at a higher rate then the tape 
rooms can write.

<cut>

>     If I really want to throw someone for a loop I ask him whether he'd
>     rather be the guy inventing the algorithm and writing the paper, or
>     the guy implementing it from the paper.  It's a question that forces
>     the questioner to actually think with his noggin.
>
>     I think that is really the crux of the problem... programmers have been
>     taught to build things from templates rather then build things from
>     concepts... and THAT is primarily why software is still stuck in the 
>     dark ages insofar as I am concerned.  True innovation requires having
>     lightbulbs go off above your head all the time, and you don't get that
>     from reading papers.  Another amusing anecdote... every time I complained
>     about something in FreeBSD-5 or 6 the universal answer I got was that
>     'oh, well, Solaris did it this way' or 'there was a paper about this'
>     or a myrid of other 'someone else wrote it down so it must be good'
>     excuses.  Not once did I ever get any other answer.  Pretty sad, I think,
>     and also sadly not unique to FreeBSD.  It's a problem with mindset, and
>     mindset is a problem with our educational system (the entire world's).

Most educational concepts are based on learning already present 
experience, nobody is educated in motivating them self to learn for the 
progress itself. This results in (besides others) not thinking outside 
the box (papers) and relying on others to make a proof of concept for 
any new technology.
Which reminds me that I don't know of any _working_ technology not being 
first implemented and tested before the paper of it was written.
Inventing is trying, writing is understanding, reading is at the best a 
recognition.

Only the ones who learn to think for/by them self have the capability to 
learn how to think outside the box, but the most falter at the first step.

>     I'm really happy that DragonFly has finally progressed to the point where
>     we can begin to implement our loftier goals.  Up until now the work has
>     been primarily ripping out and reimplementing the guts of the system with
>     very little visibility poking through to the end-user.  Now we are
>     are starting to push into things that have direct consequences to the
>     end-user.  The journaling is one of the three major legs that will
>     support the ultimate goal of single-system-image clustering.  The second
>     leg is a cache coherency scheme, and the third will be resource sharing
>     and migration.  All three will have to be very carefully and deliberately
>     integrated together into a single whole to achieve the ultimate goal.
>
>     This makes journaling a major turning point for the project... one,
>     I hope, that attracts more people to DragonFly.

Is that primarily coders or users? For me I want to switch my servers to 
DF but I am kind of waiting for a new release version where only the 
bugs and exploits are updating but no more code is introduced.

I think that overall from what I see on my test server DF is production 
ripe but I'm overly paranoid when dealing with productivity machines.

I'll planned to jump the ship from 4 to DF in July 2005 ( a matter of 
backup and reinstalling the OS) do you think there will be new release 
by then?

--
mph