Posts by dfarning

    As part of my work with OpenMediaVault on ARM I have been doing some basic performance testing. I was wondering if anyone had any suggestions for specific tests they would like to see run.

    Currently, I have two "bundles" a large file, Debian DVD, and small files, uncompressed kernel source, which I test against various file systems, protocols, and OpenMediaVault operations.

    The goal is to create a script which anyone can download and use to quantitatively determine the performance of OpenMediaVault against measures which matter to them. I am a Free Software Guy so Linux based testing is prefered otherwise, I can try setting testing from Windows in a VM.

    As an Aside, does anyone have a recommendation for a NIC to use on the testing workstation. I currently have an onboard NIC which (I think) is negatively affecting results :(

    Current Setup:

    AMD 8350 based machine with 8GB memory and 250GB SSD. (Crappy NIC)

    Dedicated Switch:
    TP-LINK TL-SG108 8-Port 10/100/1000Mbps

    Tested Device:

    How is the user experience on your WDMyCloud?

    I have been testing a few arm devices with erratic results. I think the problem is passing traffic through the switch on my wireless router. I have a new switch on order which I will use to see if I can generate some more consistent results. Can you keep you eyes open for more performance tweaks?

    While they are not going to make enthusiasts happy :( If partnered with Debian and OpenMediaVault they can be a good fit for those who are seeing the dangers of trusting their valuable data to someone else's cloud.

    Yes, that is the page the initial material was drawn from. If I recall correctly, it is licensed cc attribution 3.0. Once the initial draft is done, I like to go back and add attribution as footnotes, add references to further reading, and clean up the markup.

    Please feel free to delete anything you don't like, I am just a temporary guest in your house.

    I started drafting some ideas and created an inital structre of how people might become involved in OMV at….php?title=1.0/Contribute .

    As alway, feedback appreciated.

    With this post, my "geek weekend" comes to close. The family is coming home from their last weekend before school camping trips.... and the lawn needs mowing... and the porch needs painting. Over the next couple of weeks, I'll trying fill in the gaps and continue refining.

    So, please, use what you like, remove what you don't. See you around... just not quite as much as the last couple of days :)

    Hey all,

    Next on the todo list are FAQ and trouble shooting wiki page at and…hp?title=1.0/Troubleshoot :) Does anyone have suggestions for commonly occurring questions or problems that would fit either wiki page?

    Please feel free to add them directly to the wiki of follow up in this thread so we can consolidate the information in this forum and in the heads of forum moderators.

    Whenever someone describes how to install OpenMediaVault via Apt-get they use a two step process:

    apt-get install openmediavault-keyring postfix

    apt-get update
    apt-get install openmediavault

    Is there a reason that openmediavault-keyring and postfix cannot be made dependencies to openmediavault and save a step? A brief look around the web shows gnome-keyring being a dependency of gnome-core.

    Here is a potential mockup of the decision tree and support expectations for various install options. Items are not necessarily in the correct category as this is just a mockup for feedback on the ideas of supported vs. experimental installs and device specific installs when they are available. ( I need to figure out how to do columns... this might be more clear in two columns, one for platform installs and one for device specific installs)…hp?title=1.0/Installation

    Ok, my last item on my wiki binge this morning:)

    Can some of the oldtimers add their ideas to this thread for the top five bullet points to include in the road map page at . For consistency, these five (more or less) can evolve into the main paragraphs of the release notes.

    -Dashboard + widgets
    -BTRFS support
    -LVM snapshot support
    -WebGUI description language
    -Generic database layer

    1.0 (Kralizec)
    -Upgrade to Debian Wheezy

    To the best of my knowledge...

    0.5 sardukar is the current supported branch. I haven't seen any bugs referring to 0.5 in the tracker for awhile, so that hasn't been much need for recent updates. If you file a bug it gets fixed pretty quickly.

    0.6 Kralizec is the development branch which is leaving to a 1.0 release. I think volker had a brain fart and bumped his development tree to 1.0.0 a couple of weeks ago. As such, if you are following the branch it is already at 1.0.12. Development work on the 1.0 branch also seems to have slowed to minor bug fixes as we near release. Plugin work is continuing fast and furiously while volker creates the 1.0 images.

    I have been asking for guidance on how to communicate the release number of the upcoming formal release.

    As for an update path, I haven't tried it yet....

    Interesting, maybe we should start a table of devices.

    If others want to share their arm experiences on this thread, I can try to compile a table of installation methods and their experiences.

    BTW, Martin Michlmayr, the author of the page to which you referred, was a debian project leader in 2003. He might be able to point us in the right direction on getting the other kirkwood patches upstream and into debian proper.

    The next install question is how to install on AMR in 1.0.

    The challenge is that arm and the rest of the embedded world is kind of a zoo. In the i386 and amd64 worlds, microsoft kept things orderly by simplifying saying if a device (motherboard) didn't meet a set of specification it wouldn't boot windows. Their market dominance was enough to keep the PC world somewhat homogenous.

    Things are slightly different in the ARM ecosystem. To deal with the differences among devices, developers came up with the Device Tree. ( ) The challange for distibutions, like omv, is that each device must have a kernel custom compiled with a device specific device tree.

    This means one of two solutions (there are probably more I haven't thought of):
    1: A custom image for each device or class of device.
    2. A second recommend install method where the user installs debian for their device and then install OVM via apt-get.

    I think, what I would recommend, is that we defer the decision for another release and continue to call arm 'testing' until 1.1. I have found a bunch of little arm related issues that might take a while to fix... which are not show stoppers for i386 or amd64.

    FWIW, I am currently testing OMV on Xycel NSA325, Raspberry PI, and Beagle Bone with a Qnap TS-212P on order while working with upstream kirkwood developers to get fully functioning kernels for kirkwood processors which run most of the 1 and 2 drive NAS devices on the market.

    The next potentially contentious question is the requirement that that the OS partition not be on the same drive as a data partition. I understand the advantages of that requirement and how it is a best practice in a data center of larger NAS with several drives.

    However, in a home or small office setting which OpenMediaVault seems ideal. Many of the cost effective devices only have one or two drives. Allocating an entire drive to the OS seems excessive.

    Note: this information is for the 0.5 and 1.0 install pages at…hp?title=0.5/Installation the information is based on the 0.4 information at .