Posts by geaves

    In the linked thread Cyprus125 reached speeds of 16813K/sec which is about 10 times faster than mine

    Yes but he's using Enterprise drives, big difference, have you looked at the site he links too

    Do you have any ideas what could be the problem

    Adding 4 drives at once to an existing array, however I did find this in my watched threads which at the time I found interesting, look on page 2 around post 26, for that OP that could have gone either way

    I plugged the second hard drive into the USB2 port and the same issue still happened,

    :/ could be a faulty Pi, but afaik they use a different bus, we need the input from Soma


    and what now? do I have to start over

    I would say so and read through the official Pi installation you could install the 64bit RPi OS rather than the 32bit

    As soon as I connect the second disk to the second USB3 port on the Pi both drives start making a clicking / beeping sound in a tick-tock way

    That alone points to lack of power for both drives accessing the same USB Bus, I bet if one was plugged into a USB2 port they would be OK.

    I thinks it is totally broken

    Judging by the output you have posted on pastebin I would agree

    if i loose data it's a disaster

    That's what a backup's for

    remove all disks from OMV (write the disks order)

    - remove all disks from LaCie (write the disks order)

    - mount the LaCie disks on my OMV and create a new raid 5 with the disks in same order

    Yes and no, if the raid was created on the LaCie you have no idea if OMV will actually see the array signatures on those drives and recreate it in the GUI, if it does then it should only be necessary to mount the array, not create one


    This scenario could cause more issues than what it's worth especially if you intend to use your current OMV boot drive.


    Your first two steps are OK, but I would strongly suggest to use/deploy a fresh/clean install of OMV on perhaps a usb flash drive, update, set time etc as if this was a new setup. Then shut down install the LaCie drives and see if OMV detects the LaCie array during the boot process, which hopefully it should.

    Maybe geaves can help you

    Nope, I've read this twice and if I'm reading this correctly there are 3x3TB in a existing Raid5, to grow the array 1x3TB and 3x4TB have been added, nothing like putting an existing array under stress and to cap it off there probably isn't a backup.


    But to answer the OP's question take a look at this thread so in a nutshell can this be speeded up -> No!!

    I have just run up an OMV6 VM created a raid5 from three virtual disks and ran the cat /sys/block that I requested you run, this is the output;


    Code
    root@openmediavault6:~# cat /sys/block/md0/md/sync_actionidle

    the above is what I would expect as the system is doing nothing and the command works!! this would also show output if this was OMV5


    Yours returned -> file or directory not found, to confirm the raid reference has not changed you would have check cat /proc/mdstat, if it's still md127 then there could be some corruption. I am assuming at this point your array was created using the GUI

    If you installed OMV6 on a spare drive or usb flash drive (OMV5 and Debian 10 is EOL) once the system is up and running updates installed, date and time set etc, shut down connect your drives and during the reboot process OMV should detect the raid signatures and present the array to OMV.


    Another option might be to try systsemrescuecd in omc extras, this installs the software and should allow for the array to be assembled from the cli, exit out and reboot should bring the array back to omv. This is just a possibility, your error is quite unique, one that I have never seen nor experienced before.

    Not sure if I can help never seen anything like this before, either there is something corrupted or there is a hardware issue, as both point to the output of mdadm --detail.


    That output is missing information in relation to the array, if you look at the output from this problem;

    you can compare it to yours.


    Post the output of the following;


    blkid 

    mdadm --examine /dev/sdb

    mdadm --examine /dev/sda

    I am not really concerned about DLNA as I prefer to use network share access - it works better

    How

    In this case software has not moved forward, it has moved backwards

    Solely based on the fact that your TV cannot locate the shares on the network

    There is a fundamental change between OMV5 and OMV6 which has blocked my previous happy system

    You are basing that on what, you are failing to understand just because your 'happy system' in V5 doesn't function the same in V6 it's down to OMV when in fact your problem is Samba (SMS/CIFS) something that omv has no control over.

    If nobody can offer a solution or at least some ideas to try I will revert to OMV5 with which I had no problems

    V5 is EOL as is Debian 10 which it is based upon.

    ________________________________________________________________________


    Suggestion, not a solution, have a look in the SMB/CIFS section on here, there is possibly an option that can be added to extra options in OMV's SMB settings, as the probability is that your TV cannot communicate with the current Samba version being used on OMV.

    1. Raid md127 remove sdd-old,

    How, I am using OMV6 but I'm not using Raid and could spin up a VM but that would have to wait until tomorrow, but from memory in V5 there was an option on the Raid menu to delete/remove, that's the way a drive has to be, must be removed from an array. When done that way the array is in a clean/degraded state, so the shares and files are accessible.

    a1b1c1d1 instead of abcd

    no a1b1 etc are drive partitions, OMV does not use partitions when creating an array it uses the full drive.


    -------------------------------------------------------------------------------------------------------------------------------------------


    This output -> mdadm: Cannot get exclusive access to /dev/md127:Perhaps a running process, mounted filesystem or active volume group

    suggests that something/someone still has access to the array that's why it cannot be stopped.


    If you have the kernel plugin installed you could try using the SystemRescue option, this installs systemrescuecd and boots to that once, you can then run cli commands to assemble the array without omv running, exit and reboot will get back to omv. But, you need to check again options such as blkid.