The point about lost files with journalling file systems is well taken.
However, the use of journaling in combination with read-only partitions, can
at least guarantee (mostly, anyway) that your embedded system will continue
to function, if the disk layout is designed properly.
For our case, variable data, such as voice mail files and configuration
data, is located in the r/w partition. The /etc directory, with the all
important passwd file, and the binary applications and os binaries, are all
mounted read only. (The mounttab is a real challenge, but it can be dealt
with).
A serious abuse of the system, such as dumping the power over and over
(which customers have done, BTW!), will usually result in some lost voice
mail files, but at least the system still boots and the application (the
phone system) still works. Lost voice mail files are an acceptable
casualty, but loss of dial tone is not.
I suspect the O_SYNC would slow a pbx/voice mail system down too much to
tolerate, since you generally need 200-300 kilobytes/second throughput to
the disk in real time, for voice mail recoding and auto-attendant
interactive voice response applications. Cacheing is needed to smooth the
data flow due to the mechanical delays of the disk. For example, many
modern disks do a thermal recalibrate from time to time, which can stall
data transfer for many tens of milliseconds or more.
The best solution is always a UPS, but unless it is integrated internally,
customers will not connect it properly. And in either case the battery can
die on it, and it won't function when needed. The lead acid batteries croak
all the time in UPS's. A lost hard disk in the field for an unsophisticated
customer is big deal.
/sg
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of David Schleef
> Sent: Friday, March 19, 1999 3:33 PM
> To: Chris Albertson
> Cc: rtl
> Subject: Re: [rtl] RT linux + robots
>
>
> On Fri, Mar 19, 1999 at 02:57:41PM -0800, Chris Albertson wrote:
> > .
> > >
> > > But, I will agree that applications have a general lack
> > > of control under Linux to encourage/force certain blocks
> > > of data to get written to disk quickly or synchronously.
> >
> > What about using the "O_SYNC" flag on an open system call?
> > fsync() will do what you want also.
> >
>
> Yes... This is very true, and gets you a lot closer to
> being confident that the data is written. However, there
> is no guarantee that data is _physically_ written to the
> media, only that the hard drive has recieved the data. [1]
> O_SYNC is also really slow, since you have to wait for
> the write to complete -- not good unless you _really_ want
> it.
>
> What I had in mind is the ability to specify the order
> in which individual blocks are written -- again, this
> order may be changed by the disk controller or even the
> hard drive, so it's "soft" in the same way that O_SYNC
> is "soft". And also do it in an asynchronous manner.
>
> But I think the whole discussion is moot -- if you
> want hard guarantees, use a UPS. If you want soft
> guarantees, journaling and fsync() are good solutions,
> although at a performance loss.
>
>
> dave...
>
>
> >
> > --Chris Albertson
>
> [1] many drives don't tell you when a block has
> been written.
>
> --- [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/
>
--- [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/
