Posts by Copaxy

Quote from ryecoaaron

If you use the RPi cm4 board, you can power it with the floppy plug. So, my atx psu power the board and drives.

ahh okey. Does your atx power supply have a dc round plug? Because if i remember correctly a lot of cm4 boards have dc input

Quote from ryecoaaron

This is why I moved to the CM4 that has a pcie lane. I can use a real sata adapter - jbm585 pci-e card on the RPi breakout board or Axzez board or jmb585 m2 to sata adapter on cm4 boards with m2 slot.

ryecoaaron A quick question to your setup. If i am going to switch to a cm4 module with board and dc input, how did you power your hard drives? With another power supply? Because the board with a PCLe card just has sata data but no power.

A quick update and request for help too.

I don't know what changed in the race condition of when the driver of the sata hat loads but since a few days it mounts everytime without problems. So it seems like the kernal is not so busy in the begining and my drives load fine.

But there is a different problem.

I changed the power supply to one with 96W so it has more then enough power. No more power peaks that cause the drives to go missing hopefully. But when OMV starts and everything is fine at first then suddenly the drives go missing again but based on the logs it is because there is a superblock issue.

I also saw a snapraid content file issue when i run a snapraid status. I renamed the snapraid content file that caused he problems so it "should be fine" -> There was also data missing in the bad one.

Now this superblock issue...

In the end of the logs file it searches for each drive.

Is there someone with an idea?

syslog (4).txt

Quote from ryecoaaron

This is why I moved to the CM4 that has a pcie lane. I can use a real sata adapter - jbm585 pci-e card on the RPi breakout board or Axzez board or jmb585 m2 to sata adapter on cm4 boards with m2 slot.

Ah okey, will have to look into that.

Thanks for your help and suggesstions.

Quote from ryecoaaron

samba is a service that is waiting for local storage to start. If the disks aren't ready, it doesn't bother it.

ah understand.

Quote from ryecoaaron

mergerfs is storage that tries to wait for disks to mount pools. If the disks aren't ready, it can't mount pools and fails. There is no concept in systemd of waiting for a driver. Nothing I can do about this. The raxda hat would 1000 times better if it used an in-kernel driver instead of the weird "driver". That is why I don't use my hat.

ok true, i don't want to force you to do something about it 😅 i just wanted to understand that's all.

Quote from ryecoaaron

The behavior is inconsistent because it is a race condition. Sometimes the driver must be loaded earlier in the process. I stopped looking at it a long time ago. If someone (not me) finds a fix, I will try to add it but I'm not optimistic.

Ah okey it is a race condition, then it is more obvious why this happens.

So basically it is gambling, if i am lucky the driver loads earlier and the disks are mounted and if not then the disks are not mounted in time and mergerfs does what it did like in my case.

Yeah i also would prefer they would have an in kernal driver but it is how it is 🤷‍♂️.

Maybe i find a way around this someday or never.

Quote from ryecoaaron

The problem is the sata hat. That is why mine is a paperweight. The "driver" that allows the drives connected to the hat to be visible to the OS loads too late for systemd. I don't have any way to fix that in the plugin.

ahh okey understandable, but then i have another question.

Why when i don't set any sharefolders and smb connections the drives work rock solid and as soon as i add a mergerfs pool and sharefolders it is gambling? When i last time reset the sharefolders and mergerfs pool it worked first fluently, then after a few reboots and days it startet to get buggy any then completely stopped working. Only after repeating the whole process it works again for awhile.

I am not complaining, it is just i don't get it... if it is as you are saying and the "driver" loads to late for sytemd then wouldn't they never load properly? Then the driver would be always too late and never in time.

But the thing that confuses me is that it loads properly but after mergerfs then suddenly not, so i am thinking what leads to that the driver is loaded too late...

Or maybe something is delaying the driver loading speed that after the settings i put in it suddenly is to slow or what?

mhm

any ideas why the behaviour is so inconsistent?

I have other news. I have narrowed down the issue.

When i completely disable the mergerfs pool and delete all sharefolders my drives are mounted. So believe mergerfs is the problem here.

[Unit]
Description = MergerFS mount for MyNAS
After=network-fs.target zfs-mount.target
RequiresMountsFor=/srv/dev-disk-by-uuid-5f244b38-4472-4302-a16e-f2ad9a9e1516 /srv/dev-disk-by-uuid-33083897-f75f-461e-b784-53b1c1f67c4a /srv/dev-disk-by-uuid-d5fa5dcc-b81d-4ab2-a663-71e58f3298dc

[Mount]
What = MyNAS:7883120e-f452-424f-ae28-fcc914e484b8
Where = /srv/mergerfs/MyNAS
Type = fuse.mergerfs
Options = branches=/srv/dev-disk-by-uuid-5f244b38-4472-4302-a16e-f2ad9a9e1516:/srv/dev-disk-by-uuid-33083897-f75f-461e-b784-53b1c1f67c4a:/srv/dev-disk-by-uuid-d5fa5dcc-b81d-4ab2-a663-71e58f3298dc,category.create=mfs,minfreespace=20G,fsname=MyNAS:7883120e-f452-424f-ae28-fcc914e484b8,defaults,allow_other,cache.files=off,use_ino

[Install]
WantedBy=multi-user.target

from systemd file for the mergerfs pool

 <mergerfs>
      <pools>
        <pool>
          <uuid>7883120e-f452-424f-ae28-fcc914e484b8</uuid>
          <name>MyNAS</name>
          <mntentref>34b75c3b-ef25-4904-801a-1f87f1114977</mntentref>
          <paths>/srv/dev-disk-by-uuid-5f244b38-4472-4302-a16e-f2ad9a9e1516:/srv/dev-disk-by-uuid-33083897-f75f-461e-b784-53b1c1f67c4a:/srv/dev-disk-by-uuid-d5fa5dcc-b81d-4ab2-a663-71e58f3298dc</paths>
          <createpolicy>mfs</createpolicy>
          <minfreespace>20</minfreespace>
          <minfreespaceunit>G</minfreespaceunit>
          <options>defaults,allow_other,cache.files=off,use_ino</options>
        </pool>
      </pools>
    </mergerfs>

config.xml

All UUIDs seem correct and everything looks normal but still no clue why the error occours and omv cannot mount anything

Interesting things i found in the sys logs

Sep 12 12:43:52 MeinNAS chronyd[885]: System clock wrong by 36294.544873 seconds
Sep 12 12:43:52 MeinNAS systemd[1]: Starting Clean php session files...
Sep 12 12:43:52 MeinNAS chronyd[885]: System clock was stepped by 36294.544873 seconds

Starting File System Check on /dev/disk/by-uuid/33083897-f75f-461e-b784-53b1c1f67c4a...
Sep 12 12:44:24 MeinNAS systemd[1]: Starting File System Check on /dev/disk/by-uuid/5f244b38-4472-4302-a16e-f2ad9a9e1516...
Sep 12 12:44:24 MeinNAS systemd[1]: Starting File System Check on /dev/disk/by-uuid/d5fa5dcc-b81d-4ab2-a663-71e58f3298dc...
Sep 12 12:44:24 MeinNAS systemd[1]: Started File System Check Daemon to report status.
Sep 12 12:44:24 MeinNAS systemd[1]: systemd-hostnamed.service: Succeeded.
Sep 12 12:44:24 MeinNAS systemd-fsck[5371]: e2fsck 1.46.2 (28-Feb-2021)
Sep 12 12:44:24 MeinNAS systemd-fsck[5375]: e2fsck 1.46.2 (28-Feb-2021)
Sep 12 12:44:24 MeinNAS systemd-fsck[5377]: e2fsck 1.46.2 (28-Feb-2021)
Sep 12 12:44:29 MeinNAS systemd-fsck[5371]: /dev/sdc1: clean, 123281/244191232 files, 978327105/1953506385 blocks
Sep 12 12:44:29 MeinNAS systemd[1]: Finished File System Check on /dev/disk/by-uuid/d5fa5dcc-b81d-4ab2-a663-71e58f3298dc.
Sep 12 12:44:29 MeinNAS systemd[1]: Mounting /srv/dev-disk-by-uuid-d5fa5dcc-b81d-4ab2-a663-71e58f3298dc...
Sep 12 12:44:30 MeinNAS kernel: [  148.149384] EXT4-fs (sdc1): mounted filesystem with ordered data mode. Opts: user_xattr,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0,acl. Quota mode: journalled.
Sep 12 12:44:30 MeinNAS systemd[1]: Mounted /srv/dev-disk-by-uuid-d5fa5dcc-b81d-4ab2-a663-71e58f3298dc.
Sep 12 12:44:30 MeinNAS systemd-fsck[5377]: /dev/sdb1: clean, 230117/244191232 files, 965480490/1953506385 blocks
Sep 12 12:44:30 MeinNAS systemd[1]: Finished File System Check on /dev/disk/by-uuid/33083897-f75f-461e-b784-53b1c1f67c4a.
Sep 12 12:44:30 MeinNAS systemd[1]: Mounting /srv/dev-disk-by-uuid-33083897-f75f-461e-b784-53b1c1f67c4a...
Sep 12 12:44:30 MeinNAS kernel: [  148.799494] EXT4-fs (sdb1): mounted filesystem with ordered data mode. Opts: user_xattr,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0,acl. Quota mode: journalled.
Sep 12 12:44:30 MeinNAS systemd[1]: Mounted /srv/dev-disk-by-uuid-33083897-f75f-461e-b784-53b1c1f67c4a.
Sep 12 12:44:31 MeinNAS systemd-fsck[5375]: /dev/sda1: clean, 297800/244191232 files, 965481377/1953506385 blocks
Sep 12 12:44:31 MeinNAS systemd[1]: Finished File System Check on /dev/disk/by-uuid/5f244b38-4472-4302-a16e-f2ad9a9e1516.
Sep 12 12:44:31 MeinNAS systemd[1]: Mounting /srv/dev-disk-by-uuid-5f244b38-4472-4302-a16e-f2ad9a9e1516...
Sep 12 12:44:31 MeinNAS kernel: [  149.661438] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: user_xattr,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0,acl. Quota mode: journalled.
Sep 12 12:44:31 MeinNAS systemd[1]: Mounted /srv/dev-disk-by-uuid-5f244b38-4472-4302-a16e-f2ad9a9e1516.
Sep 12 12:44:31 MeinNAS systemd[1]: srv-mergerfs-MyNAS.mount: Directory /srv/mergerfs/MyNAS to mount over is not empty, mounting anyway.
Sep 12 12:44:31 MeinNAS systemd[1]: Mounting MergerFS mount for MyNAS...
Sep 12 12:44:31 MeinNAS mount[5504]: fuse: mountpoint is not empty
Sep 12 12:44:31 MeinNAS mount[5504]: fuse: if you are sure this is safe, use the 'nonempty' mount option
Sep 12 12:44:31 MeinNAS systemd[1]: srv-mergerfs-MyNAS.mount: Mount process exited, code=exited, status=1/FAILURE
Sep 12 12:44:31 MeinNAS systemd[1]: srv-mergerfs-MyNAS.mount: Failed with result 'exit-code'.
Sep 12 12:44:31 MeinNAS systemd[1]: Failed to mount MergerFS mount for MyNAS.
Sep 12 12:44:46 MeinNAS systemd[1]: Started Run anacron jobs.

OMV suggests me to use the nonempty mount option on the mergerfs pool but since it is not in the fstab anaymore, how can i tell omv that while booting?

Any ideas why the disks fail to mount?

Okey sorry, but i have to reopen the thread.

I don't know what it coused but since today OMV doesn't recognize my file systems anymore

Couldn't extract an UUID from the provided path '/srv/mergerfs/MyNAS'.
a few seconds ago

It also sometimes says something about that it could not find the UUID in fstab. But did not he way of mounting drives got changed so it works without fstab?

I am confused what happened or what is causing the problem....

Also another thing is when i click on some pages of OMV it shows a error for old cached data and needs to be reloaded. Somethimes i can not open a page because it always needs to reload.

Quote from crashtest

It only takes one drive to cause serious problems. A drive can fail in ways that can reset a PC or SBC. Intermittent power shorts could do it.

For future reference, that kind of issue can be isolated by disconnecting all drives (or other connected peripherals) and reconnecting them one at a time. It can be an exhaustive process, especially if the problem is intermittent, but there's no other way to be sure.

Yes true.

I did test every drive one by one and recofigured OMV6 step by step, that is why it took so long to test. But all drives had problems one day or another, so in the end i had to switch all 4.

One drive is still okey sometimes, so i use it as a external drive on pc for quick file transfer. No need to worry then when it will fail completely.

Quote

Let's assume the suppliers knows what he is doing. Then if they have a possibility to ground, it is needed. If they don't have the possibility it is not needed. Metal cases need to be grounded, plastic cases not.

Ah okey. Interesting.

Thank you for the information

Quote from macom

Then they are not grounded.

Ah okey. Thanks

Quote from macom

I would prefer one with without adapter so. One source for failure less.

i also could do it this way true.

Then if some have a grounding and some not, what is recommended? Doesn't matter what i will choose later to buy or build.

Quote from macom

If the PSU has a metal case, the ground is connected to the case. Should be provided by the documentation of the PSU.

Ahh okey, good to know. And when it has a plastic case? It is quite rare to see a propper documentaion on those units.

Quote from macom

If done correctly it is ok.

On the AC side be aware of the 230V. 230VAC can cause serious harm. Also take care of grounding (yellow/green wire)

On the DC side be aware of the polarity (+/-).

And make sure to select the correct voltage.

Okey that sounds good.

Yes i am aware of the 230VAC and the polarity.

I would like to go into more detail with the grounding. Because a SCHUKO cable has 3 seperate wires (L Phase, N Phase and Ground) but a DC transformer just has 2 inlets and outlets. So the L and N Phase should be no problem, just connect them correct as you said, but what about the grounding? How to i propper ground the whole unit?

Previously i only used normal euro connectors without ground for less then 5A devices so i have not so much experience with grounding on SCHUKO cables.

Quote from crashtest

That would be great. All too often, when users figure out what's wrong they disappear. Real world feedback for these odd issues is useful info for all.
Thanks.

Sooo. Sorry it took so long but i figured things out i guess.

Solution for the frequent restart problem:

i bought 4 new HDDs and it fixed the problem. I guess the drives where on the edge of its lifetime. My gess is that my drives suddenly went missing and OMV was not able to remount them so it restarted but it was unable to find them again. Also i made sure that no sdcard was faulty.

This solved the problem for me.

I have one more question for the electronic experts here.

Since it is not so "easy" to find a propper dc round connector power supply with like 80-90W, does it make a difference when i just take a normal SCHUKO cable, put it on a DC transformer which is capable to deliver 90W DC and connect it to a dc round cable?

I used one for a external fan setup with an noctua NA FC1 4Pin Fan control unit and also for lamps or leds.

So basically is it okey to build a power supply or bad idea?

suggestions?

Quote from Soma

Which HAT version do you have? v1 or v2?

Where i can see which version i have? i had it quite early when it got released so i believe it should be version 1, but i am not sure.

Quote from Soma

If you have the v2, you're using a 12V power supply that feed both the HAT and the Pi (as it should be).

If 60w (5A) isn't enough, get a power supply with more juice (75W or 90W).

I don't think it's a good idea to put 2x power supplies on that rig at the same time (if I read it right, 1xUSB-C on the Pi itself and the other plugged on the HAT. You're putting power on the GPIO from 2 distinct sources):

yeah true i am already looking for one with more juice.

Yes i know this is probably not the best solution but i just thought then the pi can take its juice from the pi power supply on the usb c and the other bigger power supply can power the disks.

I measured the power delivery when using the pi itself and with the HAT.

When i use just the pi it takes about 12W in idle and when i use it with the HAT and both power supplies, the pi power supply on the usb c port takes around 10-12W and the bigger HAT power supply on the (dc round connector) takes around 29-38W. The pi power supply is quite stable on point on what the pi usually consumes.

Since i don't have a new power supply, i will continue with both power supplies but when i buy a new on i get one with more power.

Update:

Since the NAS is now online since 4 days without interruption, i believe it was the power issue. For now it runs stable.

Thank you chente for trying to narrow the issue down. I just tried the additional power supply as a test so it was more of gambling but luckyly it worked :).

Quote from chente

Are the hard drives connected directly to the PI or is there an intermediate power supply?

there is a sata hat inbetween with an additional power supply.

But i think i maybe found the issue. I have one 60w power supply for the sata hat what also can power the pi itself but after the last mount issue i put the standart pi power supply additionally. So now i have two power supplies that power the pi and the HDDs.

Nothing is jet guaranteed but it is successfully online for more then one day then 6h so maybe if i am lucky it was just the high peak power draw that caused the drives to be unmounted. But i am still testing.