Beiträge von Tyberious Funk

    I've only spent a few hours playing with LXC and OMV... but I suspect the issue is that OMV is looking for a block device to mount, and your container doesn't have one. You need to expose your block devices to the LXC container that is running OMV. I have no idea if this is actually possible -- I ended up changing my approach before I could figure it out.

    Running in Jessie, I had no issues. On Wheezy, as you point out, you need a backports kernel. On a plain vanilla wheezy install, I just followed the standard process for installing from backports then ran the installation script. Basically, exactly as described on the Docker website -- https://docs.docker.com/installation/debian/


    On OMV, I don't know if there is a "preferred" method for getting a backports kernel, but I just installed the extras repository package, then installed the kernel via the interface. And then, again, installed docker from the install script they provide. No dramas. I only found a couple of minor issues with running docker from wheezy. Mostly from a few online guides that assume your system is running systemd (which wheezy doesn't).


    I think docker is going to be a big benefit to me. I use OMV for my home NAS, which has very quickly become the centre of entertainment in the house. I get more and more nervous about running and updating software on it, and the potential for breaking things, but I can't really justify buying a second development and testing box. Docker gives me the ability to isolate applications, fire up a container for temporary needs, run applications designed for different distributions or different versions of linux... it's all very nice.

    I've been playing with Docker for a couple of months now, and I'm really getting to like it. I've been using both Debian Jessie and Wheezy, and have happily developed Dockerfiles for sabnzbd, sickbeard, couchpotato, headphones, mylar and transmission. Last night I got Docker up and running in a VirtualBox instance of Krazelic, and I'm slowly testing my Dockerfiles in an OMV environment. My initial impressions are that it works very well, although you need to install the backports kernel to get it working.


    IMHO, a basic docker interface for Open Media Vault would have really big benefits. Once I got a sense of what I was doing, I found that I could put together a functional dockerfile really quickly... and I'm by no means an expert. In doing my research I discovered that unRaid has implemented a docker interface -- which I assume makes plugin development really quick for them. Previously, this was a real weakness of unRaid and now, I think, they've turned it into a strength.

    Has anyone got any experience running OMV in an OpenVZ environment? I set up a test environment to give this a try, using the following basic steps;


    1. Install a basic Debian Wheezy host system
    2. Set up OpenVZ (as per http://openvz.org/Installation_on_Debian)
    3. Create a new Debian Wheezy container
    4. Enter the virtual environment and install OpenMediaVault (as per Howto install OpenMediaVault on Debian 7.x (Wheezy))


    So far, everything seems to be working. But I'm still nervous about moving my main system to OpenVZ -- partly because it requires a custom kernel which might have compatibility issues in the future.

    Not sure I understand the problem...


    I run Sickbeard, couchpotato, sabnzbd, samba and (at various times) plex, and never had any problems. BUT... I don't use the 3rd-party plugins. Not to disparage the work of the plugin developers, but I like configuring these things my own way. Each application has it's own user, and each user has permissions for the required folders set up in the OMV interface. For example, Sickbeard has read/write access to my TVShows folders, Couchpotato has read/write access to Movies, etc, etc. I have an XBMC user for samba access to TVShows and Movies (this could be a read-only user, but I like using XBMC to save meta data and thumbnails, so it is read/write).

    Zitat von "tekkbebe"

    I think the HP Microservers are best for people that do not have the knowledge to build their own machines. If you can build your own why pay more. Your self built machine will most likely be bigger but it will be more powerful for less money.


    Can't comment on other countries, but in Australia there is no way you can build a compact server for the same price as an N54L. They typically retail here for about $220-$250. A vaguely comparable ATX system will be... about $250. But if you want a reasonable PSU, CPU Fan, and convenient drive bays... you are looking at much more. And if you want an ITX system, the cost is even higher.

    Zitat von "IamTed"

    Thanks Dave, that's exactly what I was thinking of. Any tips on how to do this as I start my Google quest on symlink & linux?
    :)


    SnapRaid does this. Although the synm-link "pool" feature is secondary to the basic purpose of snap raid.


    But basically you specify the directories you are tracking (ie, Movies A-M, Movies N-Z) and then specify a pooling directory (ie, /media/Movies). Then schedule the command "snapraid pool" as a cron job every 60 minutes and it'll automatically update the symlinks in your pool directory.


    There might be other ways of doing this, but that's one that immediately comes to mind.

    Zitat von "davidh2k"

    @Tyberios, CTRL+A +D is detach, whats CTRL+A +Z? (No need to hold CTRL for second 'letter'.)


    Sorry, you are right. Ctrl-A Z is for "suspend"... If you detach a screen (as opposed to suspending it), I believe you can re-attach using "screen -r" rather than "screen -x". But I think in practical terms, the end result is the same.


    Zitat


    Also if you run the rsync via the cronjob tab in the OpenMediaVault GUI it will run in the background, too, of course.


    True.


    On a side note, I actually found using cp in some situations is faster than rsync, particularly when copying files for the first time. Obviously, the advantage of rsync is it's incremental capabilities. So when backing up (or moving files) for the first time, I run cp, and then run rsync to pick up anything that cp might have missed.

    I've never really taken much notice of HDD benchmarks, because as long as my NAS serves my media to my media player... then it's "fast enough". Mostly, the bottleneck is going to be the ethernet cable, or the wireless network. A quick google, and it seems that 130MB/s is fairly standard for my model seagate drives. One of them seems to be running at around 120MB/s, which I'll call "good enough". The other seems a bit slower at 100MB/s, but that could be to do with some hardware bottlenecks on the server (I'm running an HP N40L with unmodified BIOS). But as you point out... it's all kind of irrelevant really... because even blu ray doesn't need high speed read access.


    So I can only assume that either repartitioning the drive might have resolved the problem... or, it's unrelated to the hard drives...


    I think all I can really try now, is to shift a few high definition rips to these drives and try some further "real world" tests.

    Zitat von "hermie"

    Hi davidh2k,


    So is there a way to do the copy within the OMV box, and not having to do it over a network to another pc ???


    I frequently refer to this guide when it comes to rsync;


    http://www.thegeekstuff.com/2010/09/rsync-command-examples/


    You can use putty to connect via ssh to your OMV box, and then use rsync to transfer data from your failing RAID array to a new drive.


    Not that it is essential, but I also like to use a program called "screen" which allows you to easily detach from your putty session while leaving tasks to continue running. You can then re-attach your session when you want to check on them.


    To install;


    sudo apt-get install screen


    To run, just type 'screen'


    You can then run your rsync.


    Ctrl-a, Ctrl-z will detach your screen, and you can safely close putty... rsync will continue to run in the background. When you log back on, you can re-attach screen by running 'screen -x', and you should see your rsync session still running. Assuming you are running rsync in verbose mode, you'll be able to see how far it has got through the transfer process.

    Both of them are 4TB seagate drives. I had them individually partitioned, each with a single ext4 partition. One was serving as a parity drive for snapraid and the other stored my ripped TV shows.


    I was concerned that, being 4TB drives, I hadn't partitioned them correctly... which is why I re-partitioned.


    FYI, here is the current partition information.


    gdisk /dev/sdb

    Code
    Partition GUID code: 0FC63DAF-8483-4772-8E79-3D69D8477DE4 (Linux filesystem)
    Partition unique GUID: 2AF31848-54D8-424A-9C74-A59271CB15D0
    First sector: 2048 (at 1024.0 KiB)
    Last sector: 7814037134 (at 3.6 TiB)
    Partition size: 7814035087 sectors (3.6 TiB)
    Attribute flags: 0000000000000000
    Partition name: 'Linux filesystem'


    /dev/sde

    Code
    Using 1
    Partition GUID code: 0FC63DAF-8483-4772-8E79-3D69D8477DE4 (Linux filesystem)
    Partition unique GUID: B6AFC3C7-4048-401A-9C8E-FB1585E4F579
    First sector: 2048 (at 1024.0 KiB)
    Last sector: 7814037134 (at 3.6 TiB)
    Partition size: 7814035087 sectors (3.6 TiB)
    Attribute flags: 0000000000000000
    Partition name: 'Test'

    I was simply using the default settings in hdparm.


    Anyway, using DD



    On the surface, these numbers seem reasonable. Am I missing something? When I used these drives to serve tv shows to my media player, I was getting constant buffering issues. I replaced the drives, and the problem disappeared.


    Could the issue have been related to partitioning? Since replacing the drives, I have re-partitioned them and re-formatted.

    Probably a good idea to set up ssh, and connect via putty or something similar. You can cut and paste the output of commands from your putty session.


    (Nothing to do with your HDD problem... but will make it easier to work with your OMV box)

    And for what it's worth, the output of hdparm -i


    hdparm -i /dev/sde


    /dev/sde:


    Model=ST4000DM000-1F2168, FwRev=CC52, SerialNo=W300DJ4W
    Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs RotSpdTol>.5% }
    RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
    BuffType=unknown, BuffSize=unknown, MaxMultSect=16, MultSect=off
    CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=7814037168
    IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
    PIO modes: pio0 pio1 pio2 pio3 pio4
    DMA modes: mdma0 mdma1 mdma2
    UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6
    AdvancedPM=yes: unknown setting WriteCache=disabled
    Drive conforms to: unknown: ATA/ATAPI-4,5,6,7


    * signifies the current active mode



    hdparm -i /dev/sdb


    /dev/sdb:


    Model=ST4000DM000-1F2168, FwRev=CC52, SerialNo=W30011TQ
    Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs RotSpdTol>.5% }
    RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
    BuffType=unknown, BuffSize=unknown, MaxMultSect=16, MultSect=16
    CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=7814037168
    IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
    PIO modes: pio0 pio1 pio2 pio3 pio4
    DMA modes: mdma0 mdma1 mdma2
    UDMA modes: udma0 udma1 udma2 udma3 udma4 *udma5 udma6
    AdvancedPM=yes: unknown setting WriteCache=disabled
    Drive conforms to: unknown: ATA/ATAPI-4,5,6,7


    * signifies the current active mode

    I'm having trouble with a couple of Seagate 4TB hard drives that seem to have inconsistent performance.


    Here's the results of running hdparm -t /dev/sde four times in a row;


    Timing buffered disk reads: 2 MB in 4.69 seconds = 436.56 kB/sec
    Timing buffered disk reads: 2 MB in 4.70 seconds = 436.05 kB/sec
    Timing buffered disk reads: 446 MB in 3.01 seconds = 148.21 MB/sec
    Timing buffered disk reads: 444 MB in 3.00 seconds = 147.94 MB/sec


    And the results for hdparm -t /dev/sdb;


    Timing buffered disk reads: 2 MB in 4.67 seconds = 438.46 kB/sec
    Timing buffered disk reads: 378 MB in 3.01 seconds = 125.77 MB/sec
    Timing buffered disk reads: 372 MB in 3.01 seconds = 123.73 MB/sec
    Timing buffered disk reads: 378 MB in 3.00 seconds = 125.88 MB/sec


    I believe inconsistent results from hdparm are not uncommon (hence why it's worth running several times). But I'm finding the slow performance is causing buffering while trying to watch movies/tv shows from my NAS. So the issue is more significant than just some fluctuations in readings. Also, both the drives are relatively new and bought from two completely different sources and have no bad sectors. It strikes me as strangely co-incidental that they are both Seagates, though... so I'm wondering if there is some kind of factory setting I need to change. I have a 4TB Western Digital Red, and it hasn't caused me any problems.

    I know it's not necessary. I just thought it might be a useful feature. My OS is on an SSD (which I'm assuming is quite common)... I wonder if having the content file on an SSD makes any kind of speed difference.

    IIRC, it is recommended (or at least, a common convention) to keep a copy of the content file in /var directory. The plugin doesn't seem to allow this.


    Is it possible to have, say, a checkbox on the plugin configuration to put a copy of the content file in /var/snapraid or somewhere similar?