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?
