sabertooth
Members
-
Joined
-
Last visited
Everything posted by sabertooth
-
Docker container is already restricted to 16g. Also, have plenty of memory available out of total 64gb installed.
-
A random scan threw this error (Fix Common Problems) unraidzfs-diagnostics-20250305-0829.zip
-
Yes, thank you. What is the location of pool cfg ?
-
Sorry @JorgeB about the delay in reply. I started to explore various options to restore the zpool. After a fresh install on the same USB drive followed by copy of the /config folder the array would fail to start including the zpool. Manual start of the array would indeed start the main Unraid array though not the zpool based one since same wasn't recognized by Unraid. I had to manually configure the zpool by adding a new pool and adding the existing HDDs to the array. This thankfully restored the zfs pool. Regarding the auto-start issue, apparently the Settings::Disk Settings:Enable auto start was disabled after the first error message (relating to corruption of USB drive). Once enabled array would restart after a reboot. Having said that I believe there is indeed an issue with zpool config restoration after copying over the /config folder.
-
Please find the screenshots as attached.
-
No back-up, but after copying the /config folder, the array doesn't start along with the zfs pool. Will try again
-
Afraid, I saved after the reboot How do I correctly restore installation along with the config?
-
Recently upgraded to 6.12.13 (more than a week). After starting the system, was greeted with above message. I have tried to reboot multiple times though the array is still offline. ZFS isn't up either. unraidzfs-diagnostics-20240912-1231.zip
-
Finally took the plunge and did an upgrade to 6.12.4 from 6.11.5. 6.11.5: ZFS(RAIDZ1) User shares with same names as zfs dataset with a link(inside the share) to zfs dataset. 6.12.4: Create a new pool, and add all HDDs. Change primary storage for all shares to zfs pool. Global Share Settings -> Permit exclusive shares. So far so good, however some shares (from within zfs pool) show Exclusive access: No After a reboot, things still remain the same. In order to enable exclusive share: Create a new new dataset on the zfs pool. Move data from old share to new share (mv source destination) Delete old share. Rename new share. I tested this with smaller dataset/share first before moving to dataset(s)/share(s) with hefty amount of data. And, this is when I lost data after moving. I should have paid attention to ZFS master plugin while it was showing no increase in dataset size even when close to 800GB data was moved. Any ideas as to what went wrong? For the first time, am now worried that other datasets might show empty. Also, how can one enable Exclusive access without having to go through this circus?
-
After upgrade to 6.11.1, ZFS dataset is no longer visible.
-
System log is flooded with below messages (after the upgrade): Sep 26 08:47:39 UnraidZFS smbd[31175]: synthetic_pathref: opening [Someone’s MacBook Pro.sparsebundle/bands/2:AFP_AfpInfo] failed Sep 26 08:47:39 UnraidZFS smbd[31175]: [2022/09/26 08:47:39.199065, 0] ../../source3/smbd/files.c:1193(synthetic_pathref) This is applicable for all shares: synthetic_pathref: opening [data/backup/Downloads/ntfs.sh:AFP_AfpInfo] failed unraidzfs-diagnostics-20220926-0853.zip
-
Finally, was able to replicate the issue with RC3 as well. Please find the diagnostics as attached. unraidzfs-diagnostics-20220324-1932-zfs-suspended.zip
-
After Extended SMART Self-test of all drives in the pool, upgraded again to RC4 from RC3. Within half an hour or so the pool was again in SUSPENDED state. Reverted to RC3, not sure what's the underlying cause. zfs was working fine with RC3 earlier. How do we debug this?
-
Thanks a lot, works as expected. Afraid the GUI pushed the notification early.
-
Update fails on 6.10.0-rc4 plugin: updating: unassigned.devices.plg plugin: downloading: "https://github.com/dlandon/unassigned.devices/raw/master/unassigned.devices-2022.03.24.tgz" ... done plugin: bad file MD5: /boot/config/plugins/unassigned.devices/unassigned.devices-2022.03.24.tgz
-
Man, I should have waited for this before moving to RC4, which caused me some grief. Back on RC3, will move once Extended Self Test is complete for all HDDs.
-
Smart test was done last fortnight, and have weekly scrub scheduled on the pool. I have built the system just last month with new Exos drives. I reverted back to RC3 and things seem to be fine for now, will schedule a SMART test right away. Do you need more verbose logging? RC3: Linux 5.15.27-Unraid. RC4: Linux 5.15.30-Unraid. Update 1: SMART short self-test passed for all the drives.
-
WIth 6.10.0-rc4, pool goes offline when an attempt is made to write something into the pool. errors: List of errors unavailable: pool I/O is currently suspended Attempting to run zpool clear fails cannot clear errors for data: I/O error state: SUSPENDED status: One or more devices are faulted in response to IO failures. action: Make sure the affected devices are connected, then run 'zpool clear'. see: https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-HC scan: scrub repaired 0B in 01:51:14 with 0 errors on Wed Mar 23 15:24:10 2022 The pool was fine till RC3.
-
Thanks, and sorry for the false alarm. Earlier I created Unraid Shares and replaced them with symbolic link to ZFS directory. Worked like charm apart from getxattr() errors, which I was fine with. However, with 6.10.0-rc3, browsing these shares and using them during VM creation wasn't an option since they simply wouldn't work. As an alternative, I moved the ZFS shares under smb-extra.conf. I have reported these under RC3, since ZFS isn't a supported FS, support isn't guaranteed.
-
Unraid 6.10.0-rc3 GUI still shows version as 2.1.0 even after update and restart. Though dmesg output shows: ZFS: Loaded module v2.1.3-1, ZFS pool version 5000, ZFS filesystem version 5 Also, am running into new issues with 6.10.0-rc3. While creating a new VM, the Unraid GUI is not able to follow a symbolic link to ZFS. "data" is a symbolic link to ZFS. This was working fine with 6.9.2. Strangely, browsing the Unraid Shares works as expected.
