<div dir="ltr">CONSIDERING DRAGONFLYBSD TO HOST OLD POINT-OF-SALE SYSTEM (doubts)<br><br>I have been following the project advances since almost 2 years.  At that<br>time I installed it once on VM and tested it for a few days. From<br>that time I kept reading and following news and material about its<br>advancements.<br><br>Ultimately I've been testing it in a VBox machine, I have 3.6, 3.8.1<br>and 3.8.2. I've installed it on a real machine for a few days, then I<br>had, in a hurry, to reinstall linux again. I like what I see and how<br>the system configures. It's really manageable. When I'm reading about<br>networking in general I now test the info using the dragonfly machines<br>instead of a virtualized linux or the host machine in itself.<br><br>I've tested a little the now-default hammer filesystem (hammer1?).<br>But not extensively because I dont wanna trash my laptop's hard disk as<br>the periodical automatic procedures run... even though I checked PFS,<br>snapshots and their workings. Again, its manageable and easy deployable.<br><br>My current concern with the OS right now is that the first days I<br>tested it on VM, it threw several kernel panics and sudden VM<br>halts. From time to time I got to think that the bug could correspond to<br>the phase when I paused the VM and the instant I continue the emulation. I<br>thought It could be ACPI stuff, that maybe the acpi procedures are only<br>oriented to work on real machines for lack of human resources, similar<br>to the decision to drop the 386 arch. Could I be right?<br><br>But to be honest, dragonfly also halted in front of my eyes with no<br>apparent reason. It also died out in the PC, twice (kernel panics). My<br>fault I dont have some pictures of that. It could be anything...<br><br>Anyways, I've been thinking and right now I have a problem where dragonfly<br>could be the base for a solution to secure the life and running time of<br>a very old POS system hosted on a SCO machine.  I'm thinking at emulating<br>the raw disk on qemu machine. I've tested it and it works. We are talking<br>about 20GB disk images. Could anyone explain me if the snapshotting<br>capabilities of hammer filesystem would handle efficiently this data in<br>both space and time matters.<br><br>Using snapshots would be a really solid feature to guarantee<br>the functioning of very old servers nobody wants to look into nor<br>debug. If they still work, the user is satisfied and trusts in it and<br>has also given her approval to say the POS servers haven't failed on<br>her in her accounting processes, then there is nothing to change, too<br>risky. Everything works fine but it WILL someday fail, and it will fail<br>hard. The snapshots would even give us the possibility of recovering<br>from any obscure bugs in the emulated OS, by restoring a previous copy<br>of the disk image. I just recently found, after several hours, that the<br>'fstab' file of the SCO server got unexpectedly deleted...<br><br>Not knowing what responses will I get, I wanna know if dragonfly on a<br>real machine will handle this 'weight'.  I consider dragonfly man pages<br>pretty accurate and very clear and that in itself provides a good deal<br>of stability.  But I can't get it out of my head: dragonfly has kernel-<br>panic'ed on me several times too. I have a few days to decide if I<br>will base on dragonfly or will have to resort to a linux solution. In<br>terms of deployment, dragonfly offers -to me- the simplest and obvious<br>direction. My final question is:<br><br>In your own opinion, could dragonfly give me stable uptimes and no<br>unexpected downtimes.  I'm considering to run qemu in pure emulation<br>(by software) so the VM doesnt play clever with the dragonfly host<br>(btw, I don't know it there is more optimized emulation supported by<br>dragonfly). Uhh?<br><br><br></div>