Posts by piet

Oh no! Stupid am I.

I thinked that it was enbled by default.

So everything is working fine now. And OMV 5 is a really excellent product.

Thank you.

Regard.

Pierre.

ps: is there a way to help the project? Because we use OMV since several years, for free. And with great help also for free. So it is time to help (donation for the project, work, ...)

Hello,

we use OMV in the Helios64 from Kobol (which is a great product by the way) with OMV 5.5.18-1 (Usul)

Everything are running fine, except the stats. We always have no more than 2 minutes....!

And no stats at all for the network and for the raid 5 (but ok for the disk where the OS was installed). See my screenshots in attachement for more understanding.

Is there a way to fix this ?

Thank you.

Regard.

Just compare the backup and the original file with Nakivo.
And all the tests are ok. No data corrupted.
Try it please, and tell us your opinion after that.

Hello @Enwood, here is a solution:

https://forum.openmediavault.o…12To-create-4-partitions/

The solution is first to use the dd command, like this :

# dd if=/dev/zero of=/dev/sdb
# dd if=/dev/zero of=/dev/sdc
# dd if=/dev/zero of=/dev/sdd

Regard.

OK.

And for Synology it was a "classic" mode, raid 1 with btrs format. But Synology maybe write other partition or strange, hiden things. It is possible.

Regard

Yes, but now there is no data at all, isn't it ? (after create raid and format filesystem in ext4)

Yes I mean delete the post number 24.

No I made a mistake, and can't delete my answer, so I just put this smiley ...
Sorry about that.
And of course my NAS run with version 4, since a long time ago...

This post is solved.

More precisely:
Failed to execute command 'export PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin; export LANG=C; mount -v --source '/dev/disk/by-id/md-name-openmediavault:raid9disks' 2>&1' with exit code '32': mount: mount /dev/md0 on /srv/dev-disk-by-id-md-name-openmediavault-raid9disks failed: Structure needs cleaning

You must do this:
# fsck /dev/md0

And, if needed, fix all errors. After that you can mount the file system.

If not try this:
# fsck.ext4 -f /dev/disk/by-id/md-name-openmediavault:raid9disks
# mount -a

This solution is tested and working for us. No data were corrupted.

ness1602: yes, thank you. I think the dd command has deleted all partions or other strange bad things from the HDD. One hdd came from a synology NAS.

@ryecoaaron : thank you for your help.

@henfri : thank you for the idea for SnapRaid. My backup'll be more secure.

Ok, mdadm may not have problem with disks of that size.

And now it is working. How ?

Like said Ryecoaaron, it was partition or something else on disks in fault.
So to be sure I just use the dd command:

# dd if=/dev/zero of=/dev/sdb


# dd if=/dev/zero of=/dev/sdc


# dd if=/dev/zero of=/dev/sdd

I stop before the end, just after +/- 250Go was writing.

And restart the creation of the raid 5.

2019-03-15_07h41_44.jpg

So it is working now. Just 981 minutes for resyncing, = +/- 15 hours, which is reasonable. YES!

Regards.

Piet

Before, I also build the raid 5 completely.

Reboot

And still same problem, the 3 bad devices are still there...

I don't understand.And is there a way to format the drive and remove all data, and partition, and other things ?

If I want to do this, it'll do this. Sprry, but I post this thread for a solution, not to have some opinions.

So, to be construtive, if someone have a solution ?

Maybe boot from ubuntu and with gparted format the 3 disks ?

Hello,

here are the result of the command cat /proc/partitions

2019-03-14_15h10_50.jpg

2019-03-14_15h13_40.jpg

But I don't know what to do now. Sorry I'm a little lost...

Regard.
Piet

Hello,

sorry, but I don't understand everything...

So I do the command cat /proc/mdstat

2019-03-14_13h08_14.jpg

But after that I don't know how to create an array with mdadm tab... Do you have documentation about this ? Sorry.

Thank you.

Regard.

Piet

update: but I'll follow : https://www.digitalocean.com/c…ith-mdadm-on-ubuntu-16-04

and if I want to create array, I said yes. Is that right ?

root@OMV:~# sudo mdadm --create --verbose /dev/md0 --level=5 --raid-devices=3 /dev/sdb /dev/sdc /dev/sdd
mdadm: layout defaults to left-symmetric
mdadm: layout defaults to left-symmetric
mdadm: chunk size defaults to 512K
mdadm: /dev/sdb appears to be part of a raid array:
       level=raid0 devices=0 ctime=Thu Jan  1 01:00:00 1970
mdadm: partition table exists on /dev/sdb but will be lost or
       meaningless after creating array
mdadm: /dev/sdc appears to be part of a raid array:
       level=raid0 devices=0 ctime=Thu Jan  1 01:00:00 1970
mdadm: partition table exists on /dev/sdc but will be lost or
       meaningless after creating array
mdadm: /dev/sdd appears to be part of a raid array:
       level=raid0 devices=0 ctime=Thu Jan  1 01:00:00 1970
mdadm: partition table exists on /dev/sdd but will be lost or
       meaningless after creating array
mdadm: size set to 11718754304K
mdadm: automatically enabling write-intent bitmap on large array
Continue creating array? 
Continue creating array? (y/n) y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md0 started.
root@OMV:~#

Oh no, it is still the same problem...

2019-03-14_13h23_58.jpg

But before it was right, no ?

2019-03-14_13h27_44.jpg

Quote from ryecoaaron

You could've used the actual command I posted
The output of wipefs indicated it didn't do anything. So, that is probably why it didn't fix anything. What is the output of:

parted /dev/sdb mklabel gpt
parted /dev/sdb print

Repeat for each drive.

Hello,

ok I did what you asked (with no raid actually)

root@OMV:~# parted /dev/sdb mklabel gpt
Information: You may need to update /etc/fstab.


root@OMV:~# parted /dev/sdb print                                         
Model: ATA ST12000NE0007-2G (scsi)
Disk /dev/sdb: 12.0TB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags: 


Number  Start  End  Size  File system  Name  Flags


root@OMV:~# parted /dev/sdc mklabel gpt
Information: You may need to update /etc/fstab.


root@OMV:~# parted /dev/sdc print                                  
Model: ATA ST12000NE0007-2G (scsi)
Disk /dev/sdc: 12.0TB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags: 


Number  Start  End  Size  File system  Name  Flags


root@OMV:~# parted /dev/sdc prin^C
root@OMV:~# parted /dev/sdd mklabel gpt
Information: You may need to update /etc/fstab.


root@OMV:~# parted /dev/sdd print                                  
Model: ATA ST12000NE0007-2G (scsi)
Disk /dev/sdd: 12.0TB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags: 


Number  Start  End  Size  File system  Name  Flags


root@OMV:~#

2019-03-14_12h28_21.jpg

The result are strange, isn't it ?

Regard.
Piet

We have a first backup (Nakivo on Synology). This is for the second backup. And, no offense, but you are off topic. Do you have a real idea to fix the problem ?

Or anybody have a idea for this problem ?

Thank you.

Regard.

Piet

Quote from cabrio_leo

Here is an interesting ZDNet article about RAID 5 from 2017 and why it can be sometimes more efficient to restore a backup instead of rebuilding a failed drive: Why RAID 5 still works, usuallyAnd another one: Why the best RAID configuration is no RAID configuration

Don't understand. I read the article, but can't see any explication about the problem here. The problem is not recontruction, it is a creation.

So if someone have a idea for the problem ?

Regard.
Piet

Quote from tkaiser

For RAID5 they're way too big unless you got some magic drives with an unbelievably amazing unrecoverable read error rate (URE). See the first answer you got in this thread.

This is not the problem. This is just my choice if I want to made a raid 5 with 3 12To disks.
The problem are the 3 stranges devices created. Strange ins't it ?

If someone have a idea to fix it ? And I suppose that OMV support 12To disk..?

Regard.
Piet