Prev: KMail column display
Next: M.I 5-Persecu tion . t he BBC , te levision and rad io
From: Folderol on 31 Dec 2007 14:41
I have an application that will be run on a fairly robust industrial
computer. The hardware side is pretty much cut and dried, but I have
concerns about the software.

The main problem is that I can absolutely guarantee that the system will
be quite frequently just switched off at the supply while running.

There is only one configuration text file that is saved (quite
frequently) and it wouldn't be a disaster if this became corrupted and
was dropped back to default settings. However, how can I protect
against corruption of other parts of the system, and less important,
avoid a long slow disc check next time the machine is rebooted.

Provisionally I'm thinking of using Zenwalk. It ticks the boxes for
fast, small & all the .dev files already in place.

--
Will J G
From: Darren Salt on 31 Dec 2007 14:58
I demand that Folderol may or may not have written...

[snip]
> The main problem is that I can absolutely guarantee that the system will
> be quite frequently just switched off at the supply while running.

Two notices, one "press briefly to shut down" pointing at the power button,
one "use the computer's power button to shut down properly" at the plug? And
have a cluebat handy :-)

I think that you want to make it easy to shut down from the power button
(requires acpid) and very awkward (at least, normally so) to switch off at
the plug or, if it has a switch, the PSU. And make sure that the BIOS's
power-off setting is _not_ "instant off"...

> There is only one configuration text file that is saved (quite frequently)
> and it wouldn't be a disaster if this became corrupted and was dropped back
> to default settings. However, how can I protect against corruption of other
> parts of the system, and less important, avoid a long slow disc check next
> time the machine is rebooted.

Use journalled file systems. I'd go straight for ext3 (except, perhaps, for
very small partitions which it takes only a few seconds to check even with
ext2).

There's not much that you can do about deferred writes short of making the
flush to disk happen sooner (/proc/sys/vm/dirty_writeback_centisecs,
/proc/sys/vm/dirty_expire_centisecs), but if the power switch takes
sufficiently long to get to, this won't really matter.

[snip]
--
| Darren Salt | linux or ds at | nr. Ashington, | Toon
| RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army
| + Output *more* particulate pollutants. BUFFER AGAINST GLOBAL WARMING.

Curiosity killed the cat, but satisfaction brought her back.
From: Andy Burns on 31 Dec 2007 15:55
On 31/12/2007 19:41, Folderol wrote:

> The main problem is that I can absolutely guarantee that the system will
> be quite frequently just switched off at the supply while running.

UPS together with NUT?

From: Folderol on 31 Dec 2007 16:17
On Mon, 31 Dec 2007 19:58:05 +0000
Darren Salt <news(a)youmustbejoking.demon.cu.invalid> wrote:

Thanks for such a quick reply.

> I demand that Folderol may or may not have written...
>
> [snip]
> > The main problem is that I can absolutely guarantee that the system will
> > be quite frequently just switched off at the supply while running.
>
> Two notices, one "press briefly to shut down" pointing at the power button,
> one "use the computer's power button to shut down properly" at the plug? And
> have a cluebat handy :-)
>
> I think that you want to make it easy to shut down from the power button
> (requires acpid) and very awkward (at least, normally so) to switch off at
> the plug or, if it has a switch, the PSU. And make sure that the BIOS's
> power-off setting is _not_ "instant off"...

Unfortunately this is not an option. In the first place, for HSE
compliance there must be an easily accessible means of quickly
removing *all* power to the machinery. This is usually necessary when
the machine crashes (much more 'interesting' than a software crash).

Secondly, the operators, who are not known for high-level thinking
processes, quickly get into the habit of hitting the isolator for even
relatively minor problems.

The use of a clue-bat would in any case be counter productive. The
heads of said operators have far greater density than the most robust
bat, and the employers would resent the cost of frequent
replacements ... of clue-bats.

> > There is only one configuration text file that is saved (quite frequently)
> > and it wouldn't be a disaster if this became corrupted and was dropped back
> > to default settings. However, how can I protect against corruption of other
> > parts of the system, and less important, avoid a long slow disc check next
> > time the machine is rebooted.
>
> Use journalled file systems. I'd go straight for ext3 (except, perhaps, for
> very small partitions which it takes only a few seconds to check even with
> ext2).

Hmmm. I was thinking of using ext3 anyway. It looks pretty mature and
well supported.

> There's not much that you can do about deferred writes short of making the
> flush to disk happen sooner (/proc/sys/vm/dirty_writeback_centisecs,
> /proc/sys/vm/dirty_expire_centisecs), but if the power switch takes
> sufficiently long to get to, this won't really matter.
>
> [snip]

Would a 'sync' after each write take care of this?

Once started, the program takes over the whole machine but uses X GUI.
If I disable logging, and shutdown almost all services, could I be
reasonably confident the OS won't be writing anything to disc once the
system is up and running?

Must-haves are: display, mouse, keyboard, usb, RS232.

--
Will J G
From: Will Kemp on 31 Dec 2007 16:56
On Mon, 31 Dec 2007 21:17:13 +0000, Folderol wrote:

> Hmmm. I was thinking of using ext3 anyway. It looks pretty mature and
> well supported.

Yeah, i'd definitely second the recommendation to use ext3. It seems to
be pretty much immune to poweroff corruption of the filesystem. I've
powered off ext3 systems loads of times without shutting down properly -
and never had a corrupted file.

> Would a 'sync' after each write take care of this?

It's probably worth doing if it's possible. But you don't know whether
the machine will be powered down during the write, whenever it happens.

> Once started, the program takes over the whole machine but uses X GUI.
> If I disable logging, and shutdown almost all services, could I be
> reasonably confident the OS won't be writing anything to disc once the
> system is up and running?

Have a look at the process table while it's running - use 'ps' - and see
what processes are running. Then work out for each process what may or
may not be writing to disk. Temp files are a possibility. As are lock
files. Neither of those are probably really that worth worrying about
though.
 |  Next  |  Last
Pages: 1 2 3
Prev: KMail column display
Next: M.I 5-Persecu tion . t he BBC , te levision and rad io