Mailing List Archive: Linux-HA: Dev

Hi list!!

Index | Next | Previous | View Threaded

i+d at ceintec

Oct 20, 1999, 1:54 AM

Post #1 of 7 (1462 views)
Permalink

Hi list!!

Hi all !!

Alan Robertson escribió:

> Pero su Engles is mucho mejor que mi Espanol :-) Hablo solo un
poquito de
> Espanol.

Wonderfull!! , I speak a few English, you speak a few Spanish, then
when I speak in Spanenglish you'll understand me. :-)

> I'll copy you a few emails from others about the gnbd project, and
related
> things in a separate mail.

Thanks, I'm reading now, there is some interesting things.
The Phillipp's nmbd sounds well, but somebody can explain me,
what does he mean by "journaling file system"?, I don't understand this
term
It's the same that a transactional file system? or It's a file system
with
permanent write operations?

>
> I'd recommend that you join the Linux-HA development list. You can
join it
> here:
> http://lists.tummy.com/mailman/listinfo/linux-ha-dev

Done.

I'm have been reading the TODO list , and I think that in a future
I would take over some task like to make a GTK-based visual front-end
or some visual tools for monitoring Heartbeat and of course an Spanish
translation of the documentation and man pages.

Now, I'm assimilatting all the information, but I hope to be usefull for
the
project soon.

I can't reply the mail every days because my ocupations, then may have
some delay.

David Martinez
--------------------------------------------------------
CEINTEC i+d i+d [at] ceintec
Investigation & Development division
48011 Bilbao SPAIN (34) 94 441 44 97

sct at redhat

Oct 20, 1999, 9:46 AM

Post #2 of 7 (1456 views)
Permalink

Hi list!! [In reply to]

Hi,

On Wed, 20 Oct 1999 09:54:42 +0100, CEINTEC i+d <i+d [at] ceintec>
said:

> Thanks, I'm reading now, there is some interesting things. The
> Phillipp's nmbd sounds well, but somebody can explain me, what does he
> mean by "journaling file system"?, I don't understand this term It's
> the same that a transactional file system?

Yes --- or rather, journaling is one method by which we can make a
filesystem transactional.

> or It's a file system with permanent write operations?

A filesystem without permanent writes is of rather limited use. :)

--Stephen

jafo at tummy

Oct 20, 1999, 10:00 AM

Post #3 of 7 (1445 views)
Permalink

Hi list!! [In reply to]

On Wed, Oct 20, 1999 at 05:46:10PM +0100, Stephen C. Tweedie wrote:
>Yes --- or rather, journaling is one method by which we can make a
>filesystem transactional.

As I understand it, the journaling in ext3 (which is a fantastic
design, BTW), only handles journaling of file-system meta-data,
not of actual file data. This is a common misconception I've run
into is that it handles the file data as well.

The problem is that in the event of a crash, there's little a file-system
can do to prevent the crashed applications data from being left in an
unknown state.

Sean
--
I used to think that the brain was the most wonderful organ in
my body. Then I realized who was telling me this. -- Emo Phillips
Sean Reifschneider, Inimitably Superfluous <jafo [at] tummy>
URL: <http://www.tummy.com/xvscan> HP-UX/Linux/FreeBSD/BSDOS scanning software.

frival at zk3

Oct 20, 1999, 10:22 AM

Post #4 of 7 (1443 views)
Permalink

Hi list!! [In reply to]

Sean Reifschneider wrote:

> On Wed, Oct 20, 1999 at 05:46:10PM +0100, Stephen C. Tweedie wrote:
> >Yes --- or rather, journaling is one method by which we can make a
> >filesystem transactional.
>
> As I understand it, the journaling in ext3 (which is a fantastic
> design, BTW), only handles journaling of file-system meta-data,
> not of actual file data. This is a common misconception I've run
> into is that it handles the file data as well.

Bzzt. As a matter of fact, all it does right now is journal both data and
metadata. Stephen mentioned that we could try turning off data logging (thereby
improving vastly the performance) but that it certainly hadn't been tested.

>
> The problem is that in the event of a crash, there's little a file-system
> can do to prevent the crashed applications data from being left in an
> unknown state.
>

Yup. Even with data logging, who is to say that the last write you did to a file
actually leaves your file in a usable state, for example? I believe that's why
Alan is so high on RAID-1+NBD - the data is written to all nodes simultaneously,
so unless your entire cluster crashes, at least someone has the right data.
Again, not super-performing (and sct has mentioned that there are tweaks we can
use) but pretty doggone stable.

- Pete

sct at redhat

Oct 21, 1999, 4:08 AM

Post #5 of 7 (1438 views)
Permalink

Hi list!! [In reply to]

Hi,

On Wed, 20 Oct 1999 11:00:24 -0600, Sean Reifschneider
<jafo [at] tummy> said:

> On Wed, Oct 20, 1999 at 05:46:10PM +0100, Stephen C. Tweedie wrote:
>> Yes --- or rather, journaling is one method by which we can make a
>> filesystem transactional.

> As I understand it, the journaling in ext3 (which is a fantastic
> design, BTW), only handles journaling of file-system meta-data,
> not of actual file data.

Actually, it journals both for now. That simplifies the journaling
core quite a bit, and I'm keeping the metadata-only journaling
disabled until I'm sure that the core journal code is rock-solid.

Full journaling will still be an option in the long term, though. In
particular, for systems such as NFS servers, fast commit of written
data to disk is necessary for low latency, and by allowing data to be
journaled to a separate journal device, we can improve NFS write
latencies enormously while retaining synchronous writes.

> This is a common misconception I've run into is that it handles the
> file data as well.

It does.

> The problem is that in the event of a crash, there's little a file-system
> can do to prevent the crashed applications data from being left in an
> unknown state.

Absolutely. Data journaling is not application journaling. You can
ensure that the data is intact on disk, but that doesn't mean that it
represents a consistent state for the application. Only the
application can ever have a hope of understanding what its own
transaction semantics are.

What filesystem data journaling _can_ offer in this situation is fast
commit of filesystem transactions to disk. This is especially true if
you have a separate journal disk, but even without that, committing
data to disk (ie. O_SYNC writes or fsync()) becomes a simple matter of
writing a single sequential record to the journal. The filesystem can
propagate the in-place updates to the main on-disk structures later on
at leisure, but the initial synchronous data write can be done much
more quickly with filesystem data journaling.

--Stephen

crispin at cse

Oct 21, 1999, 1:05 PM

Post #6 of 7 (1444 views)
Permalink

Hi list!! [In reply to]

"Stephen C. Tweedie" wrote:

> Absolutely. Data journaling is not application journaling. You can
> ensure that the data is intact on disk, but that doesn't mean that it
> represents a consistent state for the application. Only the
> application can ever have a hope of understanding what its own
> transaction semantics are.

I am very interested in process checkpoint and rollback. I wrote my
dissertation and several papers on optimistic programming several years ago (
http://www.cse.ogi.edu/~crispin/hope.html ). Optimistic programming depends
on being able to checkpoint a process now, and roll back to that state later.

I implemented a crude form of checkpoint and rollback for processes, but
couldn't do anything about rolling back file state. Can a journaling file
system give me the hooks I need to be able to checkpoint and rollback the
state of one or more files?

Thanks,
Crispin
-----
Crispin Cowan, CTO, WireX Communications, Inc. http://wirex.com
Free Hardened Linux Distribution: http://immunix.org

sct at redhat

Oct 22, 1999, 5:54 AM

Post #7 of 7 (1444 views)
Permalink

Hi list!! [In reply to]

Hi,

On Thu, 21 Oct 1999 20:05:33 +0000, Crispin Cowan <crispin [at] cse>
said:

> I am very interested in process checkpoint and rollback. ...

> I implemented a crude form of checkpoint and rollback for processes,
> but couldn't do anything about rolling back file state. Can a
> journaling file system give me the hooks I need to be able to
> checkpoint and rollback the state of one or more files?

No. The journal does not keep any form of snapshot other than a record
of the immediately outstanding IO pending on the filesystem. It would
break the journal semantics completely to have any form of long-term
snapshot in the log.

Snapshots are still useful to have, but implementing them is an
orthogonal issue to journaling.

--Stephen

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads