JorgeB

When there's a read error on one disk unRAID reads all the other disks plus parity to calculate the correct data and write it back to the the first one, that's why it's reading the same sector on several disks, and now that you know there's definitely a problem you'll need to start trying swapping things around to detect the cause, different PSU, different backplane (or temporarily connect the disks directly), etc.

Forget to mention, sometimes these things can happen one time and only one time, like a fluke, so keep using the server normally and if it happens again in the near future you know there's a problem, and start troubleshooting, there's a Portuguese saying, roughly translates to "one time is no times".

That's why it's not a disk problem, no chance several disks have the same bad sector, and why it points to a controller/connections issue. It can also be a failing backplane, failing PSU, etc.

Multiple disks failed at the same time, most likely a controller/connection/power issue, check if the disks with errors have anything in common, regarding to power and SATA cables

Yes, that's my only issue with new GUI, I don't know if @bonienlpushed for the orange since he's Dutch, but I like it, reminds me of Verstappen 😀 But look at the comparison on the button size from v6.5, I'm guessing text being all in caps might also have something to do with the button size, but IMO still too large.

Each disk being a contained filesystem is one of the biggest advantages of unRAID, but like everything it has is its downsides, like for example performance and implementing features like these, I don't see how for example dedupe can work across multiple filesystems, but I could be wrong.

All of those features are supported if you select btrfs as the filesystem, but there's currently no GUI support, I believe at least VM snapshots are planned for the near future, not sure about the others, so you can use them now but need to use the console/scripts. For example, there's a recent thread discussing compression here. One thing to keep in mind, since with unRAID all data disks are a separate filesystem these only work on a disk by disk basis, i.e., you can't dedupe a share spanning multiple disks.

Since it won't be convenient to reboot my main server for a while, used my test server to do it, same call trace with auto start disable, first diags have autostart enable and no trace, then disable and trace. test-diagnostics-20180908-1458.zip test-diagnostics-20180908-1501.zip

I will confirm and report here as soon as I can reboot the server, but the call trace is identical so expect so.

Yep, seams similar to the one I got, and I also have auto-start disable on this server, good catch.

Got a call trace on startup, functionality appear unaffected: Sep 8 09:05:48 Tower1 kernel: WARNING: CPU: 3 PID: 5826 at block/blk-core.c:781 blk_cleanup_queue+0xd5/0x16c Sep 8 09:05:48 Tower1 kernel: Modules linked in: md_mod ipmi_devintf igb i2c_algo_bit x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm ttm crct10dif_pclmul crc32_pclmul crc32c_intel drm_kms_helper ghash_clmulni_intel pcbc drm aesni_intel aes_x86_64 crypto_simd cryptd agpgart glue_helper intel_cstate ipmi_ssif intel_uncore r8169 intel_rapl_perf i2c_i801 nvme i2c_core nvme_core mii ahci libahci syscopyarea sysfillrect sysimgblt fb_sys_fops video backlight ie31200_edac acpi_power_meter ipmi_si fan pcc_cpufreq thermal acpi_pad button [last unloaded: i2c_algo_bit] Sep 8 09:05:48 Tower1 kernel: CPU: 3 PID: 5826 Comm: emhttpd Not tainted 4.18.6-unRAID #1 Sep 8 09:05:48 Tower1 kernel: Hardware name: Supermicro Super Server/X11SSM-F, BIOS 2.1a 03/07/2018 Sep 8 09:05:48 Tower1 kernel: RIP: 0010:blk_cleanup_queue+0xd5/0x16c Sep 8 09:05:48 Tower1 kernel: Code: 00 e8 75 5c 02 00 48 8b 83 98 01 00 00 48 8d b8 80 03 00 00 e8 5f 2a e0 ff 48 89 df e8 cb fe ff ff f6 83 04 02 00 00 02 74 02 <0f> 0b 48 83 7b 18 00 74 1c 48 89 df e8 12 56 00 00 48 8b 73 18 48 Sep 8 09:05:48 Tower1 kernel: RSP: 0018:ffffc900034c3bc8 EFLAGS: 00010202 Sep 8 09:05:48 Tower1 kernel: RAX: ffffffff81e32c00 RBX: ffff8808324db8d0 RCX: 0000000000000000 Sep 8 09:05:48 Tower1 kernel: RDX: 0000000fffffff01 RSI: 0000000000000000 RDI: ffff8808324dba10 Sep 8 09:05:48 Tower1 kernel: RBP: ffff8808520ca8c8 R08: 0000000000000000 R09: ffff88087789a540 Sep 8 09:05:48 Tower1 kernel: R10: 000000000048e610 R11: ffff88085054c680 R12: ffff8808324dbf98 Sep 8 09:05:48 Tower1 kernel: R13: ffff8808520c8008 R14: ffffffffa007326f R15: 0000000000000000 Sep 8 09:05:48 Tower1 kernel: FS: 000014cc517f9780(0000) GS:ffff880877980000(0000) knlGS:0000000000000000 Sep 8 09:05:48 Tower1 kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Sep 8 09:05:48 Tower1 kernel: CR2: 000000000066ceb0 CR3: 000000084f19e004 CR4: 00000000003606e0 Sep 8 09:05:48 Tower1 kernel: DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 Sep 8 09:05:48 Tower1 kernel: DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Sep 8 09:05:48 Tower1 kernel: Call Trace: Sep 8 09:05:48 Tower1 kernel: do_stop+0x45/0xab [md_mod] Sep 8 09:05:48 Tower1 kernel: stop_array.constprop.17+0x77/0x9c [md_mod] Sep 8 09:05:48 Tower1 kernel: md_proc_write+0x1223/0x163d [md_mod] Sep 8 09:05:48 Tower1 kernel: ? walk_component+0xc2/0x249 Sep 8 09:05:48 Tower1 kernel: ? proc_reg_open+0xdf/0xf9 Sep 8 09:05:48 Tower1 kernel: ? proc_i_callback+0x13/0x13 Sep 8 09:05:48 Tower1 kernel: ? _cond_resched+0x1b/0x1e Sep 8 09:05:48 Tower1 kernel: ? dput.part.5+0x33/0xea Sep 8 09:05:48 Tower1 kernel: ? path_put+0xd/0x16 Sep 8 09:05:48 Tower1 kernel: ? path_openat+0xb2d/0xc07 Sep 8 09:05:48 Tower1 kernel: ? do_filp_open+0x83/0xa9 Sep 8 09:05:48 Tower1 kernel: ? rcu_is_watching+0x5/0x9 Sep 8 09:05:48 Tower1 kernel: proc_reg_write+0x41/0x5f Sep 8 09:05:48 Tower1 kernel: ? proc_reg_poll+0x54/0x54 Sep 8 09:05:48 Tower1 kernel: __vfs_write+0x2e/0x13b Sep 8 09:05:48 Tower1 kernel: vfs_write+0xc3/0x166 Sep 8 09:05:48 Tower1 kernel: ksys_write+0x58/0xa6 Sep 8 09:05:48 Tower1 kernel: do_syscall_64+0x57/0xe6 Sep 8 09:05:48 Tower1 kernel: entry_SYSCALL_64_after_hwframe+0x44/0xa9 Sep 8 09:05:48 Tower1 kernel: RIP: 0033:0x14cc513d8e81 Sep 8 09:05:48 Tower1 kernel: Code: c3 0f 1f 84 00 00 00 00 00 48 8b 05 59 91 20 00 c3 0f 1f 84 00 00 00 00 00 8b 05 6a d5 20 00 85 c0 75 16 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 57 f3 c3 0f 1f 44 00 00 41 54 55 49 89 d4 53 Sep 8 09:05:48 Tower1 kernel: RSP: 002b:00007fff0e076ac8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 Sep 8 09:05:48 Tower1 kernel: RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 000014cc513d8e81 Sep 8 09:05:48 Tower1 kernel: RDX: 0000000000000004 RSI: 00007fff0e076b00 RDI: 0000000000000005 Sep 8 09:05:48 Tower1 kernel: RBP: 00007fff0e076c50 R08: 0000000000000000 R09: 0000000000000000 Sep 8 09:05:48 Tower1 kernel: R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000402c60 Sep 8 09:05:48 Tower1 kernel: R13: 00007fff0e076ec0 R14: 0000000000000000 R15: 0000000000000000 Sep 8 09:05:48 Tower1 kernel: ---[ end trace 0c83b66f1652334b ]--- tower1-diagnostics-20180908-0910.zip

It should, if preclear was successful unRAID would recognize the drives as cleared, it's one of the uses of preclear, but there have been some issues with the plugin lately, so likely they weren't properly cleared.

There are some new features, but to be honest except for the new GUI nothing that I will use or care for, though I understand that they are important for many users and LT needs to prioritize them. I care more for array related features, top of my head these would be the top 3: -targeted correcting parity check (fix just the sync errors detected on a previous non-correcting check) -multiple cache pools (I've been using them anyway with the help of UD for a while, but still would like a full featured version) -GUI snapshot functionality (including data disks, though I'd be happy even if just for VMs for starters, including a setting to automatically delete them after X days) edit: resumable parity check would also be nice.

If current cache is btrfs you can add and change the profile later.

Diags are unfortunately after rebooting, but disk6 dropped offline and not being detected, check connections. You should diagnostics showing this.

Because there's no need to, and the array would be offline during the parity copy, regular replacement keeps the array online.

Yes, to upgrade parity disk it needs to be re-synched, if you keep the array data unchanged you can keep the old parity during the sync in case there's a problem.

Yes, parity swap is only for when you need to replace a data disk and you have a disk larger than current parity, if you just want to upgrade parity just do a standard replacement.

You have to assign the old parity to disk7, new parity to parity slot, after both are assigned you will get the copy button.

Really liking the new GUI look, maybe except the very large orange buttons, like already mentioned by others. I do have one request, but since there was talk of LT taking over the UD plugin soon not sure if I should still bothering @dlandonwith this, there's a lot of extra space between disks on UD compared to the array disks, the mount/unmount buttons could also be smaller. P.S. I was expecting (read hoping) for a few new features on 6.6, can we expect some during the various rc releases, à la 6.4 or will it be more like 6.5, i.e. mostly bugs and security fixes?

You're likely missing some step during the procedure, reboot and start over, if still the same post in what step you're stuck.

Yes, parity swap will work fine for that scenario, assuming you're on one of the latest releases, since I can't see on that screenshot.

I not really following what's the current array state, and instead of having to read large threads it would much easier if post a current array screenshot and tell which disk you want to parity swap.

If there's no copy button you're doing something wrong. Much better to not use it anymore, lots of problems with Marvell controllers and unRAID, get an LSI instead.

No need to reassign anything in unRAID, disks are tracked by serial, not port/controller.