CONSIDERING DRAGONFLYBSD TO HOST OLD POINT-OF-SALE SYSTEM (doubts)

[brau]

CONSIDERING DRAGONFLYBSD TO HOST OLD POINT-OF-SALE SYSTEM (doubts)

I have been following the project advances since almost 2 years.  At that
time I installed it once on VM and tested it for a few days. From
that time I kept reading and following news and material about its
advancements.

Ultimately I've been testing it in a VBox machine, I have 3.6, 3.8.1
and 3.8.2. I've installed it on a real machine for a few days, then I
had, in a hurry, to reinstall linux again. I like what I see and how
the system configures. It's really manageable. When I'm reading about
networking in general I now test the info using the dragonfly machines
instead of a virtualized linux or the host machine in itself.

I've tested a little the now-default hammer filesystem (hammer1?).
But not extensively because I dont wanna trash my laptop's hard disk as
the periodical automatic procedures run... even though I checked PFS,
snapshots and their workings. Again, its manageable and easy deployable.

My current concern with the OS right now is that the first days I
tested it on VM, it threw several kernel panics and sudden VM
halts. From time to time I got to think that the bug could correspond to
the phase when I paused the VM and the instant I continue the emulation. I
thought It could be ACPI stuff, that maybe the acpi procedures are only
oriented to work on real machines for lack of human resources, similar
to the decision to drop the 386 arch. Could I be right?

But to be honest, dragonfly also halted in front of my eyes with no
apparent reason. It also died out in the PC, twice (kernel panics). My
fault I dont have some pictures of that. It could be anything...

Anyways, I've been thinking and right now I have a problem where dragonfly
could be the base for a solution to secure the life and running time of
a very old POS system hosted on a SCO machine.  I'm thinking at emulating
the raw disk on qemu machine. I've tested it and it works. We are talking
about 20GB disk images. Could anyone explain me if the snapshotting
capabilities of hammer filesystem would handle efficiently this data in
both space and time matters.

Using snapshots would be a really solid feature to guarantee
the functioning of very old servers nobody wants to look into nor
debug. If they still work, the user is satisfied and trusts in it and
has also given her approval to say the POS servers haven't failed on
her in her accounting processes, then there is nothing to change, too
risky. Everything works fine but it WILL someday fail, and it will fail
hard. The snapshots would even give us the possibility of recovering
from any obscure bugs in the emulated OS, by restoring a previous copy
of the disk image. I just recently found, after several hours, that the
'fstab' file of the SCO server got unexpectedly deleted...

Not knowing what responses will I get, I wanna know if dragonfly on a
real machine will handle this 'weight'.  I consider dragonfly man pages
pretty accurate and very clear and that in itself provides a good deal
of stability.  But I can't get it out of my head: dragonfly has kernel-
panic'ed on me several times too. I have a few days to decide if I
will base on dragonfly or will have to resort to a linux solution. In
terms of deployment, dragonfly offers -to me- the simplest and obvious
direction. My final question is:

In your own opinion, could dragonfly give me stable uptimes and no
unexpected downtimes.  I'm considering to run qemu in pure emulation
(by software) so the VM doesnt play clever with the dragonfly host
(btw, I don't know it there is more optimized emulation supported by
dragonfly). Uhh?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dragonflybsd.org/pipermail/users/attachments/20141008/9d62dd0c/attachment.html>