Xili

Hello thanks for the help, it must have come from there. The reconstruction was successful

thank you this problem speaks to me, I may have already been confronted with it before restarting parity-sync, could you confirm that i can change the order of the HDDs, since parity is no longer validated, that shouldn't be a problem? (for organizational reasons for me). edit : new diagnostics after ram frequency change tower-diagnostics-20240928-1417.zip

tower-diagnostics-20240928-1214.zip

Hello I've come to ask for help because I'm having trouble redoing the parity. In fact, it systematically stops during the process. I tried to reduce the size of the array, I followed as I had already done this video: https://www.youtube.com/watch?v=nV5snitWrBk But when I was about to delete the disk, script remove disk, it didn't seem to be finished according to the script, but I had no more activity on the disks. So I decided to go ahead and remove the disk and run a parity check ... but at one point the writing seemed to stop (as with the erasing), the rebuild/check time increased and nothing happened. I've tried several times to restart the process by recreating the array with Tools/New Config, but the result is the same. it doesn't work. I even found myself without web access to unraid, which meant I couldn't see the status of the rescontruction.... I don't understand why the rebuild stops, I don't have any errors on the disks, after rebooting, they're all there. The adaptec 72405 card doesn't seem to have any problems.... how to proceed? this morning I noticed some things in the logs that seemed suspicious, but that I don't understand: Sep 28 01:08:58 Tower kernel: R13: ffff88815c2c0fb8 R14: 0000000000000007 R15: 0000000000000009 Sep 28 01:08:58 Tower kernel: FS: 0000000000000000(0000) GS:ffff888ffeb00000(0000) knlGS:0000000000000000 Sep 28 01:08:58 Tower kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Sep 28 01:08:58 Tower kernel: CR2: 00000000005b8110 CR3: 000000000220a000 CR4: 00000000003506e0 Sep 28 01:08:58 Tower kernel: ------------[ cut here ]------------ Sep 28 01:08:58 Tower kernel: WARNING: CPU: 12 PID: 22540 at kernel/exit.c:814 do_exit+0x87/0x923 Sep 28 01:08:58 Tower kernel: Modules linked in: md_mod nfsd auth_rpcgss oid_registry lockd grace sunrpc zfs(PO) zunicode(PO) zzstd(O) zlua(O) zavl(PO) icp(PO) zcommon(PO) znvpair(PO) spl(O) iptable_nat xt_MASQUERADE nf_nat xt_connmark nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xt_mark iptable_mangle xt_comment xt_addrtype iptable_raw wireguard curve25519_x86_64 libcurve25519_generic libchacha20poly1305 chacha_x86_64 poly1305_x86_64 ip6_udp_tunnel udp_tunnel libchacha ip6table_filter ip6_tables iptable_filter ip_tables x_tables bridge stp llc bonding tls r8169 realtek edac_mce_amd intel_rapl_msr edac_core intel_rapl_common iosf_mbi kvm_amd video drm_kms_helper kvm drm crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel sha512_ssse3 sha256_ssse3 wmi_bmof sha1_ssse3 aesni_intel nvme backlight crypto_simd i2c_piix4 cryptd ahci syscopyarea input_leds sysfillrect sysimgblt aacraid rapl i2c_core k10temp ccp nvme_core fb_sys_fops joydev led_class libahci wmi tpm_crb tpm_tis tpm_tis_core tpm button Sep 28 01:08:58 Tower kernel: acpi_cpufreq unix [last unloaded: md_mod] Sep 28 01:08:58 Tower kernel: CPU: 12 PID: 22540 Comm: unraidd0 Tainted: P S B D O 6.1.79-Unraid #1 Sep 28 01:08:58 Tower kernel: Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./B450M Pro4 R2.0, BIOS P5.70 10/20/2022 Sep 28 01:08:58 Tower kernel: RIP: 0010:do_exit+0x87/0x923 Sep 28 01:08:58 Tower kernel: Code: 24 74 04 75 13 b8 01 00 00 00 41 89 6c 24 60 48 c1 e0 22 49 89 44 24 70 4c 89 ef e8 c9 fb 80 00 48 83 bb b0 07 00 00 00 74 02 <0f> 0b 48 8b bb d8 06 00 00 e8 cb fa 80 00 48 8b 83 d0 06 00 00 83 Sep 28 01:08:58 Tower kernel: RSP: 0018:ffffc90015917ee0 EFLAGS: 00010286 Sep 28 01:08:58 Tower kernel: RAX: 0000000080000000 RBX: ffff88815bfdcec0 RCX: 0000000000000000 Sep 28 01:08:58 Tower kernel: RDX: 0000000000000001 RSI: 0000000000002710 RDI: 00000000ffffffff Sep 28 01:08:58 Tower kernel: RBP: 000000000000000b R08: 0000000000000000 R09: 3030303030303020 Sep 28 01:08:58 Tower kernel: R10: 3a34524320303030 R11: 6130323230303030 R12: ffff8881058f7000 Sep 28 01:08:58 Tower kernel: R13: ffff8881027a18c0 R14: 0000000000000000 R15: 0000000000000000 Sep 28 01:08:58 Tower kernel: FS: 0000000000000000(0000) GS:ffff888ffeb00000(0000) knlGS:0000000000000000 Sep 28 01:08:58 Tower kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Sep 28 01:08:58 Tower kernel: CR2: 00000000005b8110 CR3: 000000000220a000 CR4: 00000000003506e0 Sep 28 01:08:58 Tower kernel: Call Trace: Sep 28 01:08:58 Tower kernel: <TASK> Sep 28 01:08:58 Tower kernel: ? __warn+0xab/0x122 Sep 28 01:08:58 Tower kernel: ? report_bug+0x109/0x17e Sep 28 01:08:58 Tower kernel: ? do_exit+0x87/0x923 Sep 28 01:08:58 Tower kernel: ? handle_bug+0x41/0x6f Sep 28 01:08:58 Tower kernel: ? exc_invalid_op+0x13/0x60 Sep 28 01:08:58 Tower kernel: ? asm_exc_invalid_op+0x16/0x20 Sep 28 01:08:58 Tower kernel: ? do_exit+0x87/0x923 Sep 28 01:08:58 Tower kernel: make_task_dead+0x11c/0x11c Sep 28 01:08:58 Tower kernel: rewind_stack_and_make_dead+0x17/0x17 Sep 28 01:08:58 Tower kernel: RIP: 0000:0x0 Sep 28 01:08:58 Tower kernel: Code: Unable to access opcode bytes at 0xffffffffffffffd6. Sep 28 01:08:58 Tower kernel: RSP: 0000:0000000000000000 EFLAGS: 00000000 ORIG_RAX: 0000000000000000 Sep 28 01:08:58 Tower kernel: RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 Sep 28 01:08:58 Tower kernel: RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 Sep 28 01:08:58 Tower kernel: RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 Sep 28 01:08:58 Tower kernel: R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 Sep 28 01:08:58 Tower kernel: R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 Sep 28 01:08:58 Tower kernel: </TASK> Sep 28 01:08:58 Tower kernel: ---[ end trace 0000000000000000 ]--- Just to clarify, the server's motherboard was changed last week because the old one seemed to be dead. The new card ran the server correctly for a week. I'm able to mount the server on another installation without using the adaptec 72405 card, is this worth testing? thank you for your help

hello (sorry for the google translation) i used unbalanced a few years ago to reduce the size of the array, i followed this video without any problems: today i try to do the same, but during the move, the files do not seem to be moved, but copied, that is to say that the original disk remains full. But above all the only target disk is full while it has room to receive everything, as if the hardlinks of radarr and sonarr were poorly recognized, and therefore were copied twice do you have any idea of the origin of the problem? Thanks

apres plusieurs essais de recontruire les disque en erreurs , j'avais trop de soucis de lecture sur le 3eme , donc ça ne donnait rien .... Je suis finalement repartir en créant une nouvelle config en remettant en place les disque que j'avais remplacé ( le tout l'ayant pas evolué ou tres peu dans le lapse de temps), plusieur recheck apres et voila

oui le tout est a nouveau fonctionnel grace a l'aide que j'ai reçu

Hello Sorry for the response time, it's been a busy week.... I did the checks indicated above and ended up restarting everything + moving the important files to a single disk, so I know if a disk is critical or not... , and I will have to quickly put an external backup in square . For the ram, I let you see my screenshots of the bios, impossible to manually modify the frequency, I can only go down to 2667 as I have with the xmp deactivated

after research in the bios, and in the doc next door, I can't find a way to go below 2667 edit : or do I have to go to 3733 in dual, to do 1866 on each?

a non correct parity check ? I'm not sure what it is? ok so for the ram I am with 4 bars with a 2700, so I put them at 1866, correct?

hello the parity check finally finished earlier, it has accelerated well beyond 6to, 180mb/s, because none of the disks are larger than this size by those of partition for the moment Last check completed on Wed 09 Nov 2022 02:43:02 PM CET (today) Duration: 1 day, 14 hours, 5 minutes, 54 seconds. Average speed: 102.1 MB/s Finding 1465130620 errors I have not yet restarted my containers, but a priori nothing prevents it, everything seems ok to me? I am posting my diagnostics here. Is there anything shocking in it? Small question: I have 2 disks of 16to to inject and put in parity since they are the biggest, to pass the 14to in the array. What is the best way to avoid taking risks? I imagine that it is better to avoid changing the two at once, but rather one by one. But during this change can I immediately integrate the 14 into the array instead of another, or is it better to do it in two steps? tower-diagnostics-20221109-1747.zip

yes I took over the old parity disks first. yes it does not every me, it's a lot of rewriting to do. And I haven't restarted any service on the side to limit disk usage so that it's as fast as possible. This should end Thursday morning. I will get back to you at that time.

Hello The recovery of my important files is completed without any particular worries. I launched the parity check, obviously a lot of error in the parity, I suppose because of the checks started during reading problems. I imagine that it is the rewrites on the disc which make the check is slower than normal 80mb/s against 120 in normal time

ok, so I launched the array with the config, before restarting anything I get back what I didn't want to lose. It's quietly copying from the network to another machine at 90mb/s, hoping there are no errors or corrupted files. For the rest do you think that I will resume my use as before or do I need to do some checks? doing a parity check seems necessary I think Thank you for this first step

ok , strange because no matter whether I check the box or not , I have this which is put on my parity disks: "All existing data on this device will be OVERWRITTEN when array is Started" Given what you tell me, it might be safer to start with the parity disks, and then replace them 1 by 1 I admit that I am a bit cautious, and I would like to take as little risk as possible

OK Does this pose a problem if I replace my two 14to parity disks with 16to, so that I can add the 14to instead very soon? or is it better to start with the original parity disks first?

when you say before starting the array, that is to say that I start in maintenance? with valid parity checked and then I run a parity check

I initially changed the 2(2to) 5(3to) 6 (3to) drives to 6to, the replaced drives were functional, but 7 years old in operation, so I wanted to take them out for security reasons...funny to write this now reconstruction of 2 and 5 OK,and during the reconstruction of 6, error, and disc 2 fail the 3 initial disks 2(2to) 5(3to) 6 (3to), have not moved they are on the side, and I know which one (normally) During the disk 6 reconstruction error (or after) I had a disk 2 read error message, it is this disk that seems to be causing problems with the stability of the array and creates latency with the controller I guess. since the change of discs, there has not been much done on the array. even if during the reconstruction of the disks the containers were in operation, everything is on /appdata in the nvme cache. Only my Nextcloud Data folder may have undergone changes (I'm not sure) the only big things launched since we were a parity check that I canceled because it was very very slow. attempts to rebuild the new disk with many errors found and at the beginning I had launched the array to try to recover some files, but it was only reading I guess you're going to offer me to create a new configuration with the old disk location?

no I currently have no other card, several years that I have this one without worries (or I did not realize it). Formerly it managed my raid 6, but since my switch to unraid, it just serves me to reassemble the disk individually, I had also put it in a particular mode, maybe that's the problem? I'm not sure I understood the problem, what's wrong with the card? what are the errors?

very fast start this time, I started in maintenance mode tower-diagnostics-20221106-1425.zip

OK, I disabled IOMMU, remove everything that was on the pci. There remains only adaptec card that I changed port, and it is well fixed, and the nvme cache. I did not dare to start the array (even in maintenance), for fear of making things worse, because I have: - disk 1 which appears deactivated by unraid - disk 5 seems OK, but not formatted, and I guess empty - new disc 6 tested OK, which appears disabled by unraid. I await your instructions. Thank you for your help

Well Unraid tried a rebuild with the two 8TB drives after the array booted. worries, one of the two discs is in error, the other is going to the end (strangely fast reconstruction and a lot of errors) ... but does not seem to be exploitable "Unmountable" surely because it does not have been forced at the beginning of the process. And during all that disk 1 is put in error, while it is a priori good it doesn't seem terrible to me tower-diagnostics-20221105-0039.zip

start edit : screen add 🙄 tower-diagnostics-20221104-2120.zip

array is starting ..... very slowly Array Starting•Mounting disks... tower-diagnostics-20221104-2103.zip

thanks for reply with or without new 8to hdds