create raid 1 on a blank disk, copy from a drive and grow the raid

    Quote from geaves

    ?( what is that!! that has nothing to do with OMV that is already added to a mounted file system on OMV


    OK I'm out of this thread, good luck with whatever you are trying to do

    it's a way to save checksum of a file in the filesystem to detect silent data corruption in case of disk failure.


    I have told what I' tryng to do: backup to other disks and save checksum inside filesystem. OMV can be configured adding user_xattr . It's just add an external utility for the checksum calculating, verifyng and store inside filesystem

    omv 6.1.5-2 (Shaitan) | arm v64 | Helios64 | 5.15.89-rockchip64 kernel

    geaves here about silent data corruption

    Silent data corruption really is real.
    2 months ago I ran cshatag [1] on around 500GiBs of data. Today I rsync'd it to a new drive and re-ran cshatag. I was shocked to discover 31 files...
    www.reddit.com


    How to detect silent data corruption?
    Aside of filesystems like btrfs, ReFS or ZFS, are there any filesystem independent tools that can be used to detect silent data corruption or...
    www.reddit.com

    omv 6.1.5-2 (Shaitan) | arm v64 | Helios64 | 5.15.89-rockchip64 kernel

    Stop spamming this thread with external links, please.

    What you're trying to achieve is outside OMVs scope.


    Just format the drives with btrfs and create subvolumes and use SNAPPER.


    Either search the web or see my signature for some links.


    Or just have a 3-2-1 backup and you will always have a failsafe copy of DATA

    ok no more external links, just 2 things (I don't want use btrfs and I can't use zfs):

    1. Can I encounter some issues running "omv-salt deploy run fstab"?


    2. if I want remove array and use the only single unit actually in the raid (named md0) as simple disk what command I should use?

    omv 6.1.5-2 (Shaitan) | arm v64 | Helios64 | 5.15.89-rockchip64 kernel

    I'll only reply to:

    Quote from n1tr0usOx1d3

    1. Can I encounter some issues running "omv-salt deploy run fstab"?

    This command will remake the file /etc/fstab with the info taken from the /etc/openmediavault/config.xml


    If you edited fstab, it will be overwritten.

    If you changed anything on the <mntent> sections of the config.xml, they will be passed onto fstab.


    Be VERY CAREFULL with what you change.

    You can leave your system crippled and, even not able to boot.


    The "Rule-OF-THUMB" is to make a backup copy of config.xml PRIOR to any editing on it.

    ok, problem is that here https://docs.openmediavault.org/en/6.x/various/advset.html is write that to read env variables should run "omv-env get <VARIABLE_NAME>" where VARIABLE_NAME that interest me is "OMV_FSTAB_MNTOPS_EXT4" taken from here https://docs.openmediavault.or…/various/fs_env_vars.html. Running "omv-env get OMV_FSTAB_MNTOPS_EXT4" no values are showed, moreover running "tune2fs -l /dev/sdb1 | grep 'Filesystem features'" the feature "user_xattr" is not present even if it's present in /etc/openmediavault/config.xml file. I don't have any change in config.xml file, but however I want to be sure that running "omv-salt deploy run fstab" system will not be crippled.


    Quote from Krisbee

    :rolleyes: very happy to make laugh to You, but making backup as suggested in the first post and using as main device one of the 2 disk, the other disk however will be turn on and however, as all mechanical hard disks, will increase cycle count even if his scope was backup only and not main use. So consider that however will be in function, then was better make raid. After I have think about the box to link to usb port that can be turned on only for backup scope, then I have choose to don't make raid and make simple backup adding, if possible, the silent data corruption check to ext4 file system so that, for each backup, immediately it's possible notify issue.

    omv 6.1.5-2 (Shaitan) | arm v64 | Helios64 | 5.15.89-rockchip64 kernel

    Edited 2 times, last by n1tr0usOx1d3 ().

    Quote from n1tr0usOx1d3

    even if it's present in /etc/openmediavault/config.xml file.

    sudo omv-showkey fstab


    lsblk


    And what do you want to do with that attribute "user_xattr"? Add it to the options of the drive on fstab?

    Quote from Soma

    sudo omv-showkey fstab


    lsblk


    And what do you want to do with that attribute "user_xattr"? Add it to the options of the drive on fstab?

    if I run sudo omv-showkey fstab it's present in opts xml element, with tune2fs -l /dev/sdb1 | grep 'Filesystem features', lsblk and cat /proc/mounts it's no showed ... even omv-env get OMV_FSTAB_MNTOPS_EXT4 don't show any value

    omv 6.1.5-2 (Shaitan) | arm v64 | Helios64 | 5.15.89-rockchip64 kernel

    Quote from n1tr0usOx1d3

    if I run sudo omv-showkey fstab it's present in opts xml element, with tune2fs -l /dev/sdb1 | grep 'Filesystem features', lsblk and cat /proc/mounts it's no showed ... even omv-env get OMV_FSTAB_MNTOPS_EXT4 don't show any value

    Since you don't post what I ask, I give up.


    Good luck.

    Quote from Krisbee

    All I can say is that n1tr0usOx1d3 has given us a good laugh in this thread. :)

    n1tr0usOx1d3 It was joke on your "nitrous oxide" name, but not at your expense. But perhaps that was lost in translation.


    You must admit there's been many twists and turns in your saga, making it very hard to follow.


    Haven't you been told that OMV6 creates ext4 filesystems with ""user_xattr" already set? You can see that in 3 ways in OMV6.


    1. contents of the file /etc/mke2fs.conf

    2. contents of /etc/fstab

    3. the output of a command like "cat /proc/fs/ext4/sda1/options | grep xattr"


    I really don't why you are messing around with ENV VARIABLES or config.xml. By the way results of "omv-env get .... " are blank unless the specific env variable has been set by a OMV user.

    Edited 4 times, last by Krisbee: correct typos ().

    Quote from Soma

    Since you don't post what I ask, I give up.


    Good luck.


    sudo omv-showkey fstab


    <fstab>

    <!--

    <mntent>

    <uuid>xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx</uuid >

    <fsname>xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx|xxx x-xxxx|/dev/xxx</fsname>

    <dir>/xxx/yyy/zzz</dir>

    <type>none|ext2|ext3|ext4|xfs|jfs|iso9660|udf|.. .</type>

    <opts></opts>

    <freq>0</freq>

    <passno>0|1|2</passno>

    <hidden>0|1</hidden>

    </mntent>


    -->

    <mntent>

    <uuid>79684322-3eac-11ea-a974-63a080abab18</uuid>

    <fsname>/dev/mmcblk0p1</fsname>

    <dir>/</dir>

    <type>ext4</type>

    <opts>noatime,nodiratime,defaults,commit=600,errors=remount-ro</opts>

    <freq>0</freq>

    <passno>1</passno>

    <hidden>1</hidden>

    <comment></comment>

    <usagewarnthreshold>85</usagewarnthreshold>

    </mntent>


    <mntent>

    <uuid>b667270f-7c02-4f41-9ba0-2c1382ea9d9c</uuid>

    <fsname>/dev/disk/by-uuid/27e56c23-d740-4314-b3c3-64e56b4d2421</fsname>

    <dir>/srv/dev-disk-by-uuid-27e56c23-d740-4314-b3c3-64e56b4d2421</dir>

    <type>ext4</type>


    <opts>defaults,nofail,user_xattr,usrjquota=aquota.user,grpjquota=aquota. group,jqfmt=vfsv0,acl</opts>

    <freq>0</freq>

    <passno>2</passno>

    <hidden>0</hidden>

    <usagewarnthreshold>95</usagewarnthreshold>

    <comment>RAID WD60EFRX</comment>

    </mntent>


    <mntent>

    <uuid>2bfe9a24-8f24-4d3d-beca-99c6382762f2</uuid>

    <fsname>/dev/disk/by-uuid/3b033dfa-6362-444c-943e-c7615ab68e80</fsname>

    <dir>/srv/dev-disk-by-uuid-3b033dfa-6362-444c-943e-c7615ab68e80</dir>

    <type>ext4</type>

    <opts>defaults,nofail,user_xattr,usrjquota=aquota.user,grpjquota=aquota. group,jqfmt=vfsv0,acl</opts>

    <freq>0</freq>

    <passno>2</passno>

    <hidden>0</hidden>

    <usagewarnthreshold>95</usagewarnthreshold>

    <comment></comment>

    </mntent>

    </fstab>


    lsblk


    NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT

    sda 8:0 0 5.5T 0 disk

    └─md0 9:0 0 5.5T 0 raid1 /srv/dev-disk-by-uuid-27e56c23-d740-4314-b3c3-64e56b4d2421

    sdb 8:16 0 5.5T 0 disk

    └─sdb1 8:17 0 5.5T 0 part /srv/dev-disk-by-uuid-3b033dfa-6362-444c-943e-c7615ab68e80

    mmcblk1 179:0 0 14.6G 0 disk

    mmcblk1boot0 179:32 0 4M 1 disk

    mmcblk1boot1 179:64 0 4M 1 disk

    mmcblk0 179:96 0 29.7G 0 disk

    └─mmcblk0p1 179:97 0 29.4G 0 part /



    ok, all 3 method conferm that user_xattr is setted... so, there doesn't be issue compiling and running cshatag

    omv 6.1.5-2 (Shaitan) | arm v64 | Helios64 | 5.15.89-rockchip64 kernel

    Quote from macom

    Where did you get the idea that the speed of reading or writing is better for RAID1 than for a single drive?


    And what do you mean with "the backup should be scheduled"?

    Not to derail this discussion (which of course means this could derail this discussion) ...


    Regarding increased read speed from a RAID 1 array...it depends on the device/software of course, and also on how the data is accessed.

    However mdadm used in OMV can increase read speeds, if/when multiple files are accessed simultaneously, at least according to the RAID1 section of the md manpage:

    Quote
    Note that the read balancing done by the driver does not make the RAID1 performance profile be the same as for RAID0; a single stream of sequential input will not be accelerated (e.g. a single dd), but multiple sequential streams or a random workload will use more than one spindle. In theory, having an N-disk RAID1 will allow N sequential threads to read from all disks.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!

Register Yourself Login