fpabernard

Just to say that I set up my Helios64 with LK5.8.16, it's up for 2 days, it copied 12TB of data over eth1 at 100Mbits/s from another OMV server (using rsync). So till now, I do not see the point of freezing kernel updates ... Frédéric

Thanks ! MergerFS seems to be nice ! I am questioning about performance and the algorithm for moving files across filesystems is rather tricky, and does not eliminate totally errors, as they say here. For now I stay with my bind mounts, and manage to copy/remove the few files which fails when moving (which can occur as I use syncovery which tries to move files when possible). Note anyway that rsync does not move files, it copies/deletes. The advantage of MergerFS is that it manages space on the merged FS, but this is not yet a problem for me, the balance between my 2x16To is OK for now. I will reconsider when free space become a problem and needs to be equally shared between both FS.

Hello, I am exactly in the same scenario. However, if you carefully read the man pages of rsync, you'll see they recommand using bind mounts. Refer also to the man pages of mount. The caveats : - you should choose a set of directories to be "bind mounted" according to the size of target filesystems underneath - you can not move a file across real volumes underneath (you must copy and delete), so some move commands can fail - you must set up /etc/fstab manually to make the bind mounts But with that feature, you can rsync a filesystem bigger than 16TB on your source.

Hello If you do a refresh of Helios4, it would be nice to use a 64bits SoC, as filesystems are limited to 16 TB in Linux 32 bits. However, as is, sure : Helios4 is the most suitable ARM card to build a NAS, and it is also nice to have an "all-in-one" package to build it (especially the case) Frédéric

The installation worked. XFS is now supported (I made a try with successfully creating an XFS filesystem on a USB key) But when I mount the large filesystem : mount <..> on <..> failed : File too large I'm afraid that I did not anticipate that armv7 is 32bits and on 32 bits kernel FS are limited to 16 TB. Am I right ? Fred

Thanks for responding so fast. I understand that XFS is available as a module in these kernels (but not in the OMV prebuilt image). Will OMV load them or should I modify a configuration file ? I see there is two Debian Jessie images available : https://cdn.kobol.io/files/Helios4_Debian_Jessie_4.4.112.img.xz with a 4.4.112 kernel https://dl.armbian.com/helios4/Debian_jessie_default.7z with a 4.4.115 kernel and this image Armbian_5.40_Helios4_Debian_jessie_default_4.4.115.img So logically I should start with the the second one ? Fred

Hello I just started my new Helios4. The hardware is incredible and it's very easy to have a running Openmediavault running system, so the job is great but ... I used to have a Cubox and could run OMV on it (see here Installing Openmediavault on a CuBox (ARM machine)) At that time in 2012, I had to rebuild a kernel to get GPT, LVM, XFS, etc. support. As I want to use my Helios4 as a backup device (I have another Openmediavault server on classical x64 machine), I use XFS because I have huge filesystems (24 TB) and I found this filesystem to be very reliable (I have a XFS running now for 10 years, which i grew several times but never had to rebuild it). So I built a copy of this FS (using 2 x 12 TB drives) using GPT and LVM. Helios4 recognizes immediately the volume after installing LVM2 plugin for OMV. But it can not mount the XFS filesystem (but the XFS commands are present in the Linux image). So I suppose the prebuilt kernel does not include XFS support. I know that on old ARM kernels XFS seemed to be buggy, but I never had any problem with it on my Cubox. I did not find a very clear documentation for rebuilding a kernel for Helios4. Perhaps you could include XFS by default on the helios4 kernel for OMV, as this filesystem is supported by default, including the GUI for creating new FS ? Best regards F.Bernard