[[6.12.6] Strange disk error on POOL disk (all shares are gone or empty)]

IcyBox uses SATA-Controllers connect with crappy USB-Controllers that are specifically troublesome on linux - thats also why they dont support Linux.

 

I have one too and its simply unfixable by Hardware-Design.

 

If you can send it back, otherwise sell it and use plain and simple SATA, if you cant eSata, or if you really need to use USB - look into Terroristen because they support Linux officially or are at least using hardware that works properly without any bigger bugs (from the countless reviews I've seen, not by my own experience).

 

Then again, I won't recommend USB for your array unless you really can't avoid it ... as a backup target or pool it might be fine ... 

[6.12.6 smartctl (and a few other things) causing 100% CPU and unresponsivness]

It could be your NVMe:

 

Jan 10 10:23:37 Tower kernel: BTRFS info (device nvme0n1p1): relocating block group 2234621362176 flags
Jan  4 16:18:00 Tower kernel: BTRFS info (device nvme0n1p1): device deleted: missing

 

But there's also a SEGFAULT and OOM @ Plex in your syslog above ...

 

Seeing this is an N5105 maybe its related to a stuck C-State, or a BIOS-Setting making this unstable.

 

Is this a NAS-Board perhaps or an Odroid H2/H3?

 

Before looking into the Board/CPU that I'd try to really eliminate the typical culprints properly - Memory first. 

 

I would personally run the Memory Test for at least 48 hours to see if it's not really missing anything ... some of them are really hard to track. 

 

Jan  3 00:20:01 Tower kernel: Modules linked in: xt_nat xt_tcpudp veth xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xfrm_user xfrm_algo iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xt_addrtype br_netfilter xfs md_mod zfs(PO) zunicode(PO) zzstd(O) zlua(O) zavl(PO) icp(PO) zcommon(PO) znvpair(PO) spl(O) tcp_diag inet_diag ip6table_filter ip6_tables iptable_filter ip_tables x_tables efivarfs af_packet 8021q garp mrp bridge stp llc r8169 realtek i915 x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm drm_buddy i2c_algo_bit ttm drm_display_helper drm_kms_helper crct10dif_pclmul processor_thermal_device_pci_legacy processor_thermal_device drm crc32_pclmul mei_pxp crc32c_intel ghash_clmulni_intel sha512_ssse3 processor_thermal_rfim processor_thermal_mbox sha256_ssse3 sha1_ssse3 mei_hdcp intel_rapl_msr wmi_bmof aesni_intel intel_gtt processor_thermal_rapl i2c_i801 nvme crypto_simd intel_rapl_common cryptd agpgart int340x_thermal_zone intel_cstate i2c_smbus ahci mei_me
Jan  3 00:20:01 Tower kernel: i2c_core libahci intel_soc_dts_iosf nvme_core syscopyarea mei sysfillrect sysimgblt tpm_crb iosf_mbi thermal video fb_sys_fops fan tpm_tis tpm_tis_core wmi backlight tpm intel_pmc_core acpi_pad button unix [last unloaded: realtek]
Jan  3 00:20:01 Tower kernel: ---[ end trace 0000000000000000 ]---
Jan  3 00:20:01 Tower kernel: RIP: 0010:unlink_anon_vmas+0x67/0x137
Jan  3 00:20:01 Tower kernel: Code: 6b 08 48 89 ef 49 8b 75 00 e8 42 e5 ff ff 49 8d 75 50 48 89 df 48 89 c5 e8 7c 42 fe ff 49 8b 45 50 48 85 c0 75 0a 49 8b 45 48 <48> ff 48 38 eb 29 48 8b 43 18 48 89 df 48 8b 53 10 48 89 42 08 48
Jan  3 00:20:01 Tower kernel: RSP: 0018:ffffc9000e6e7ce8 EFLAGS: 00010246
Jan  3 00:20:01 Tower kernel: RAX: ffff0081049f1068 RBX: ffff8881e4f9a3c0 RCX: ffff8881e4f9a3e0
Jan  3 00:20:01 Tower kernel: RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
Jan  3 00:20:01 Tower kernel: RBP: ffff8881049f1068 R08: 000000000000000c R09: ffff88822e6d1800
Jan  3 00:20:01 Tower kernel: R10: 0000000000000001 R11: ffff88822e6d1808 R12: ffff88821f5ea990
Jan  3 00:20:01 Tower kernel: R13: ffff8881049f1068 R14: ffff88821f5ea9c8 R15: dead000000000100
Jan  3 00:20:01 Tower kernel: FS:  0000000000000000(0000) GS:ffff88856c080000(0000) knlGS:0000000000000000
Jan  3 00:20:01 Tower kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Jan  3 00:20:01 Tower kernel: CR2: 000014dc800f31e0 CR3: 0000000195136000 CR4: 0000000000350ee0
Jan  3 00:20:01 Tower kernel: note: startCustom.php[14117] exited with preempt_count 1
Jan  3 00:20:01 Tower kernel: Fixing recursive fault but reboot is needed!

 

In the end it can be also the Power Supply that's the third culprint I'd look at ...

[[6.8.3] shfs error results in lost /mnt/user]

If I go back accross the posts here - shfs seems likey is only the layer it will crash in the end.

 

See this report here:

 

https://github.com/libfuse/libfuse/issues/589#issuecomment-857484504

 

libfuse is basically in life-support-mode - since 2021

 

This could likely hit all Nix & BSD systems using a FUSE filesystem in the end depending on the edge case they trigger.

 

Interstingly in the same issue mergefs is mentioned:

https://github.com/trapexit/mergerfs/issues/965

 

I think I encountered something simliar on Debian 9 with OMV, Snapraid + MergerFS myself which was much more serious in regard to file losses (which is why I moved to Unraid myself).

 

So be careful if you try to use MergerFS/Snapraid (similiar issues)

 

There are so many layers that can possibly cause these issues, most likely pointing towards that this could also be caused by shfs itself very well because Open-Source development of it has been discontinued for 20 years now (heh).

 

The good thing with Unraid is that you can easily downgrade - and stay on a version that stays stable for you too.

 

You dont have to upgrade.

 

Things like this will happen with all Distros. Just trying to put some common sense here, I very much respect your decision / move too and also see the need for Unraid evolving more towards ZOL and possibly replacement layers ...  

 

I personally went the Synology -> Kubernetes + Distributed FS route before going back to OMV and in the end Unraid ...

Enterprise solutions so full of issues flagged as stable that I consider this all a breeze in comparission (yea I know how that sounds, might be very well a user issue too 😅)

[[6.8.3] shfs error results in lost /mnt/user]

14 hours ago, Lignumaqua said:

Had my first experience of this yesterday and it's completely repeatable. I'm in the middle of consolidating my data disks from 4TB to 8TB drives. As part of this process I've been using Unbalance to move files from old disks to new. This has all been working fine until it came to trying to move my Seafile folder structure. Seafile, if you don't know, stores all files as small chunks and there are millions of these small files in the folder structure - something over 6 million in my case.

 

Very soon after Unbalance enters the planning stage on all these tiny files, the system loses all shares. Only way back is to reboot. I'm not blaming Unbalance at all here, instead I suspect it is something to do with the sheer volume of files that are being opened, the space needed to store that data, or the rate of doing so. I have no hard evidence for which it is, other than this happened every time I tried to use Unbalance on this folder set, and Unbalance handles every other folder on my system with no problems.

FWIW - I am now moving the files using rsync from the command line but without the planning step and that seems to be working.

 

 

Unbalanced is something I wouldn't recommend honestly if you value your files (sorry, just being honest).

 

If you need a multi-threaded move that is much faster then rsync then use rclone copy ... you can install rclone via the Nerd Tools Plugin. Afterwards do a rsync for the proper permissions and be done with it .. Terminal only thought.

 

Nothing Click & Point.

 

In addition to that:

 

Seafile is something you shouldn't use on Spinning Rust - and anything simliar unless you know what you're doing. You will need to control the block size/pack size and adjust it accordingly because any HDD will struggle with that amount of files.

(I have lot more files by the way ... and never had that issue on any of my two Unraid devices so far).

 

You shouldn't move files to /mnt/user/[shares] anyway unless you know what you're doing - its much smarter to target the individual disks yourself - that way you're also avoiding the overhead.

 

So /mnt/disk[n]/sharename ...

 

If you're using ZFS you might want to make sure the pool is created on the individual disk before doing so and that it's not just a plain folder ... if there are still troubles well then this might be a bug.

 

---------

 

On-Topic:

 

Besides this it all seem like sympthoms - not example the root cause. Try fixing an error you have no root cause for is like searching for a needle in the haystack (even more so if you dont have access to the hardware). So if moving to Ubuntu helped you - so be it. I personally (almost) lost a shit ton of stuff from to workstations running enterprise hardware running on Ubuntu LTS in the last two years due to fucked up updates - good luck with that. But then again these were powered by quite more modern hardware too ... so not comparable. Then again in the last 4 years I also had several issues with Ubuntu Servers and their Auto-Updates onlegacy hardware too ...

 

If I'd recommend anything then it would be something like OpenSuse Thumbleweed - or a more "trustable" stateless distro.

 

Good luck with your venture, and dont let the negative emotions eat you away.

[Unraid OS version 6.12.0-rc5 available]

Thanks for the explanation. So far I'm quite happy with 6.11 already ... got everything working that I wanted and everything is fast and snappy even without my 10GBe NIC that didn't arrive yet ... will have to switch USB-Stick anyway so might as well start from scratch if things go south, but its also a good way to try backup/restore/migration and evaluate my own backup routines that I'm going to have with Unraid.

 

As far as ZFS specifically ZOL with Docker goes:

 

My experience with that was pretty abysmal on a really high end Dell Workstation with Ubuntu LTS.

 

At least for development with a lot of docker builds and containers ...

 

On OpenSuse I switched to XFSfor Docker straight from the start (instead of BTRFS) because that had the least overhead. Right now I'm evaluating btrfs because of the subvolumes, bitrot and snapshot possibilities. Its also what I'm using day to day on OpenSuse Thumbleweed for everything else and didnt have any issues all this time.

[Unraid OS version 6.12.0-rc5 available]

New user here - I'm just evaluating 6.11 as a trial account and will purchase a version.

 

I guess I will have to start from scratch in 6.12 ... since the storage conceptual changes sound just to much to bother migrating from the start (dont have to much setup yet). 

 

I'm wondering: I'm using an 8TB SSD-Only Array (btrfs encrypted, all storages) - right now without parity, not using pools at all.

 

From the description it sounds like things like bind-mount and the way you can now decide to not use the array at all that this is favoring SSD-Only pools too. Is there any kind of advice to be given? I do plan to add a SSD-Parity drive to prepare for failures too.

 

I'm really confused about bind-mount and how it works however ... not just that also in regards to TRIM support. I did find some topics in regards to SSD-Pools but nothing specific / official.

 

So - is there any good guide coming up in regards to that - or maybe a forum post that I can read (that I didnt find yet) ?