[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gfs-devel
Subject:    Re: Transactional Filesystem support
From:       Johnnie Peters <jpeters () sting ! phx ! mcd ! mot ! com>
Date:       1999-05-29 19:12:16
[Download RAW message or body]



On Fri, 28 May 1999, Mark Butler wrote:

> "Stephen C. Tweedie" wrote:
> 
> > And yes, you _have_ to have such a locking API.  The pessimistic
> > approach of locking everything the application touches doesn't work: for
> > performance, you simply cannot serialise all access to /var/spool/mail,
> > for example.
> 
> Absolutely. That's where a DLM comes in. If serialization is a bottleneck, you
> redesign the application.  The primary goal is guaranteed reliability first,
> performance later.  
> 
> There is no way of guaranteeing absolute reliability for most filesystem based
> applications unless the filesystem has an option to journal data.  Support for
> transactions would be a nice bonus.
> 
> > >  Standard timeout algorithm
> > 
> > Doesn't work if a transaction is so large that it takes minutes, or
> > hours, to run.  And yes, such transactions do occur in the database
> > world.  
> 
> The key here is lock acquisition time, not transaction duration.  Ideally,
> programs that run long running transactions should acquire locks up front rather
> than risk a lock acquistion failure, and consequent rollback hours into a
> lengthy transaction.  

Can an application afford to lock everything up front.  Doing this does
not inidcate goot system citizenship.

> 
> > And by the time you've finished doing this, you've added so many new
> > error calls to be detected that you effectively have a new API.  Might
> > as well do it in user space.
> 
> A transaction failure originating in a supporting filesystem would be roughly as
> likely and should be handled roughly the same way as running out of storage
> space.
> 
> > Databases regularly deal with them.
> 
> Oracle does, but most databases tend to lock up the universe before completing
> such large transactions.

I worked on the internals of a data base for 3 years.  If a system that locks 
the word may do some kind of data control but can not really be called a
database.  Real databases must allow multiple users to simultaneously access
data and locking control was definitly one of the big topics of discussion
at Software AG.

>  
> > This is not a kernel-space problem.
> 
> No one is trying to force all filesystems to handle transactions.  I just would
> like a few kernel hooks to allow at least one filesystem with transaction
> support.  Transactional filesystems are at best a research topic for now, but
> some of us need the hooks in order to do the research.
> 
> I do hope that journalling filesystems provide a mode for journalling data
> writes in the near future.  That would be *extremely* useful for mission
> critical systems.
> 

I am in total agreement about the journalling.

> - Mark
> 
> -- 
> Mark Butler	       ( butlerm @ middle.net )
> Software Engineer  
> Middle.Net
> (801)-451-4583
> 
> ------------------------------------------------------------------------------
> Linux HA Web Site:
>   http://www.henge.com/~alanr/ha/
> Linux HA HOWTO:
>   http://metalab.unc.edu/pub/Linux/ALPHA/linux-ha/High-Availability-HOWTO.html
> ------------------------------------------------------------------------------
> 
> 

To unsubscribe from this list: send the line "unsubscribe gfs-devel" in
the body of a message to majordomo@lcse.umn.edu

[prev in list] [next in list] [prev in thread] [next in thread]