RE: [rtl] RT linux + robots

[Steve Gehlbach]

Journaling file systems record a log of disk activity so that un-sync'ed cache activity can be reconstructed and the disk recovered on power up, by rolling back or rolling forward the disk transactions, much like a data base rolls back/forward data transactions. 

 

Journaling file systems are made by companies such as Veritas, and by our experience at NexPath, work very well.  It appears on the mount table as a different partition type, in this case a vfx partition instead of an s5 partition.

 

We have used the Veritas Journaling File System, along with read-only partitions, in the NexPath telephony servers, and with three years of field experience, in the hands of unsophisticated users, have never lost a hard disk due to unceremonious shutdowns.  The underlying OS is ATT Sys V R4, now Unixware, as re-marketed by VenturCom with real-time extensions.  We still have the users click a button to sync the disks before power off, but many systems have been dumped over and over without any problems.

 

It would be nice to see Linux and RT Linux get a similar file system.  We have written and released GPL'd Linux drivers for our telephony cards, but have yet to release the complete system due to the lack of a journaling file system, among other issues. Drivers are at ftp://ftp.nexpath.com/pub/linux for those that may be interested.

 

Regards,

 

Steve

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Mike Cravens
Sent: Thursday, March 18, 1999 11:17 AM
To: Paul Koning
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: [rtl] RT linux + robots

Is this what is meant by a " journaling" file system?

I have a friend who wrote a piece of software that had to recover from crashes in the middle of i/o.
He used a circular i/o buffer with a set of input and output pointers that were atomically updated following a valid record write or read.  So no partial writes or read were possible, protecting the structure.  The most recent pointers were saved,  in his case,  I believe, to be recovered after re-boot.  There are probably many variations on this involving different methods of record locking and pointer recovery.

In terms of recovering from a crash in mid-swap,  the implemtation isn't obvious to me.

Regards,

Mike Cravens

Paul Koning wrote:

>>>>> "S" == S ANCELOT <[EMAIL PROTECTED]> writes:

 > OK, but I will need an IDE magnetic hard disk .

 > To allow my system to work perfectly, do I have to partition as
 > follow :

 > /var, /tmp : ram disk on which all temporary and log files should
 > be redirected /usr linux system ...  first partition read only
 > mounted /home second partition rw

 > user data will be stored on hard disk /home partitions.  After
 > writing to this partition is there a way or configuration mode to
 > be sure that all data will be synced on disk immediatly after a
 > few ms and nothing remains in memory ?

If you use some BIG capacitors you may get several seconds of running
time after a power failure.  That's like a UPS but much simpler.

There's a mechanism in Linux to do automatic shutdown if the UPS
indicates that the line power is gone.  You might be able to tie into
that.  (I don't know how it works but you might find it mentioned in
/etc/inittab or documentation about that file.)

 > I agree that if a shutdown happens while saving user data, they
 > will be corrupted (any kind of system will have the same problem)

Not true, actually.  "Log based" file systems have the nice property
that they recover from crashes no matter when the crash occurred.
There's been some mention of a log based file system for Linux, don't
remember any details but that may be just the thing.

        paul
--- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
----
For more information on Real-Time Linux see:
http://www.rtlinux.org/~rtlinux/

-- 
  Alcatel USA              Internet: [EMAIL PROTECTED]
  1000 Coit Road Plano, Texas 75075
  **** The opinions expressed are not those of DSC Communications, Inc ****