[Helios64 Support]

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

[Helios4 Support]

7 hours ago, gprovost said:

 

What you say concern people mounting on a 64bit Kernel a File System created on 32 bit Kernel.

 

This is not the issue we are talking about. Our limitation is that simply you cannot address a File System > 16TB with a 32bit Kernel because of page cache limitation. I'm not aware of possible work around even with other File System than EXT.

 

The only solution is to use a FUSE union file system to merge two or more partitions into one big volume.

MergerFS : https://github.com/trapexit/mergerfs (It's available as a Debian package.)

 

@9a3eedi @fpabernard You guys don't want to give a try to MergerFS ?

 

 

 

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.

[Helios4 Support]

17 hours ago, 9a3eedi said:

Hi, as a user of Helios4 I wanted to give my feedback as a user, and something I'd like to see in the next iteration of this board, if it ever happens.

 

I have been using my Helios4 for a while now as a backup (via rsync) NAS to my main Synology NAS. I have 2x 8TB drives + a 3TB drive + 2TB drive, configured with lvm to make a large JBOD volume. This is a backup NAS so any failures can be tolerated (I'll simply make a new volume and backup again) 

 

I absolutely love it, and love how cost effective it is. This is the perfect solution for my backup needs, I can use my left over consumer grade hard drives in JBOD and they spin down for 99% of the time.

 

There's just one thing that really annoys me about it, and that the CPU is 32-bit. When I tried to configure my LVM, I had a limitation of 16TB volumes maximum, and this is due to the use of a 32-bit CPU if I understand correctly. If I tried to do it, the entire system would simply hang during filesystem formatting. This was something I wasn't aware of when I purchased the thing, and now I'm stuck trying to figure out how to sort files into what volume. I would really like to see a future NAS board that uses a 64-bit CPU, for example ARM64.

 

I would also appreciate if something has a solution to getting volumes larger than 16TB.

 

 

 

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.

[Helios4 Support]

7 hours ago, gprovost said:

Hahah cool to hear that. The idea of Helios4 was to fulfill one specific scope : NAS. There are a lot of awesome boards out there but often they are trying to do too many things.

For instance if we do a refresh of Helios4 with a new SoC that has some display output, I'm pretty sure we would decide to not expose it... in order to stick to a pure headless NAS server concept.

Well we hope we will carry on this path of "disruptive" DIY NAS solution with future project, but it's not tomorrow that we will steal the market share of entry level proprietary NAS

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

[Helios4 Support]

1 hour ago, Igor said:

IMO you don't need to touch anything. OMV uses our kernel from repository without changes.

 

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

[Helios4 Support]

21 minutes ago, Igor said:

Official OMV for ARM hw is Armbian based. What you look for is enabled by default on both kernels:

 

 

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

[Helios4 Support]

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