magic144

sounds good - thanks for the confirmation well, meanwhile if anybody has a way for me to definitively debug the OS-builtin main page parity check correct/nocorrect (via checkbox/start button) behaviour, I'm all ears and a willing victim/participant

yeah i mostly wanted to report here in case the GUI correct/nocorrect switch was an OS issue (not specifically related to the Parity Check Tuning plugin) i haven't noticed this before (Unraid starting the WRONG correct/nocorrect) type of parity check DESPITE the GUI checkbox when starting a manual check from the main page i only tried the parity.check nocorrect command as a means of ENSURING the right kind of check was going to be started, in the face of this uncertainty from the GUI/checkbox (which i have always used in the past, not ever having the Parity Check Tuning plugin ever installed before) @itimpi , if i do start parity check via cmdline this way, won't that be the same as if i had started via the GUI? - i assume if i start it via the parity.check cmdline, i will still have the benefits of being able to resume after a shutdown, etc i don't know how to debug the basic behaviour (bug) from the non-plugin (OS-builtin) parity start mechanism from the main page - it just seems to have been the "wrong" type sometimes - I ALWAYS want to use a "nocorrect" test as part of my monthly parity verification ritual BEFORE i decide what to do next if there is an error

syslog uploaded none of this is to do with a parity check running at boot - this is all (ONLY) about manually starting parity checks from the GUI main page

parity check started with wrong type not much i can say or offer in evidence about this, but having just updated to 7.2.4 i encountered a parity check started as the wrong type (i.e. "correct" vs "nocorrect") even though I very deliberately UN-checked the checkbox prior to starting i have also just recently installed the Parity Check Tuning plugin (2026.01.09), in case that has any relevance here - am using MS Edge on Win 11 25H2, everything up-to-date i had initially run a no-correct check, then cancelled it in order to do a flash backup with array stopped after re-starting array and then (again having un-checked the box) manually starting (a new) parity check, i noticed that it was actually running a CORRECTING parity check Tower2 kernel: mdcmd (36): check correct in the log it might be some weird browser caching problem, i really don't know what to say i stopped and started again and it was running nocorrect as i expected i stopped and started again and it was running correct again frustratingly this most recent time i tried it (after cancelling from a nocorrect condition), i deliberately did a CTRL-F5 re-load of the main page before de-selecting the correction check-box, re-started and i see nocorrect in the log in any event, i will have to be very diligent when starting parity checks in future if it might be doing what i specifically DON'T want it to be doing! update: it seems i can use the parity.check nocorrect command to initiate a parity check to have a degree of certainty in future FWIW, here is the syslog: tower2-syslog-20260308-1521.zip though it doesn't confirm anything about the state of the GUI checkbox at the times i was trying to initiate the checks activity in the syslog AFTER Mar 8 09:00:21 was me cancelling/re-launching the parity check via the parity.check cmdline

Oh cool, thanks! I didn't realize. And funnily enough I just installed UD on here today too, since I have it on my newer array (not only, but also, for its little sibling, UD Preclear). I still remember the good old days of having preclear_disk.sh as a manual script (provided by Joe L) and fighting through a series of Unraid OS updates to try and keep it working 🙃

This is the baby 🙂. 17 years young this month! MD-1510/LI Gallery Back when LT even built and tested the HW (I still went with Greenleaf for my 2nd box, having an experienced outfit put one of these things together is invaluable). Was just taking a look last night at how I could use the other 2 DIMM slots and double the RAM 4->8 GB. Might come in handy yet.

Finally bit the bullet and upgraded 6.12.6 -> 7.0.1 (offered) -> 7.2.4. Still using old faithful from-LimeTech MD-1510/LI Media Storage Server (circa 2009, still going strong). Had to remove /previous folder mid-flow to allow Flash backup tool to run (4 GB RAM), but otherwise no hiccups. Finally removed NerdTools (deprecated v7+) and went with un-get to re-install vim and screen. Currently running overdue Parity-Check (90 days since previous) to verify server stability.

Update: performed full parity check this past weekend - NO errors on disk detected...

Update: 4 more UNC "READ FPDMA QUEUED" errors showed up via the dd test so far during the course of today.

Yeah. I ran the one extended SMART last yesterday when it was "unwell". Took nearly 24 hours. Problem with it is it keeps failure info "internal" i.e. not exposed to the kernel/OS, but it did run down the Raw_Read_Error_Rate until threshold failure. It (the extended test) did not add any info to the internally logged Comprehensive Error Log/Device Error Count. Will probably run a parity check next. Still no errors recorded on this boot via CRC checking of the 1100+ GB moved onto it last time during the "rocky" period. Admittedly that's not (now) testing the parity disk, but it's giving me peace of mind on what was written onto the array previously. Parity check will give a more comprehensive result.

Alright, thanks again. Will just have to keep my eye on it. Maybe stress test it with dd from time-to-time 🙂

Thanks @JorgeB. It is surprising, though, that whilst the previous (with-errors) boot session was still active, these "read errors" could be readily triggered (e.g. via dd), but since rebooting, they appear to have disappeared. One would imagine that the intermittent nature of a media error would be just that, not limited to one particular boot cycle vs another. This seems to smack of a weird internal glitch in the drive from boot. It "got out of bed on the wrong side that day" almost! Another Q. Isn't it the case that if a disk finds a sector to be unreadable, it would be marked as "pending reallocation"? No such incidents have been noted in the SMART data. Thanks again.

Wondering if anybody else has seen anything like this. I was doing some file archiving from PC to my RAID array a couple of days ago (using TeraCopy to CRC-verify the moves). Everything appeared to have gone fine (no hint of errors at the OS/app level from the actual file transfers) and I was about to shutdown the array when I noticed on the main UI tab that there were READ errors on the parity drive (14TB WD, /dev/sdb) over the course of the day. Inspection of the syslog showed stanzas like this: Oct 12 22:06:27 Tower2 kernel: ata3.00: exception Emask 0x0 SAct 0x80f80020 SErr 0x0 action 0x0 Oct 12 22:06:27 Tower2 kernel: ata3.00: irq_stat 0x40000008 Oct 12 22:06:27 Tower2 kernel: ata3.00: failed command: READ FPDMA QUEUED Oct 12 22:06:27 Tower2 kernel: ata3.00: cmd 60/00:98:80:ac:5a/04:00:a5:05:00/40 tag 19 ncq dma 524288 in Oct 12 22:06:27 Tower2 kernel: res 43/40:f8:88:ac:5a/00:03:a5:05:00/40 Emask 0x409 (media error) <F> Oct 12 22:06:27 Tower2 kernel: ata3.00: status: { DRDY SENSE ERR } Oct 12 22:06:27 Tower2 kernel: ata3.00: error: { UNC } Oct 12 22:06:27 Tower2 kernel: ata3.00: configured for UDMA/133 Oct 12 22:06:27 Tower2 kernel: sd 4:0:0:0: [sdb] tag#19 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=DRIVER_OK cmd_age=7s Oct 12 22:06:27 Tower2 kernel: sd 4:0:0:0: [sdb] tag#19 Sense Key : 0x3 [current] Oct 12 22:06:27 Tower2 kernel: sd 4:0:0:0: [sdb] tag#19 ASC=0x11 ASCQ=0x4 Oct 12 22:06:27 Tower2 kernel: sd 4:0:0:0: [sdb] tag#19 CDB: opcode=0x88 88 00 00 00 00 05 a5 5a ac 80 00 00 04 00 00 00 Oct 12 22:06:27 Tower2 kernel: I/O error, dev sdb, sector 24249019520 op 0x0:(READ) flags 0x0 phys_seg 128 prio class 2 Oct 12 22:06:27 Tower2 kernel: md: disk0 read error, sector=24249019456 ... Oct 12 22:06:27 Tower2 kernel: md: disk0 read error, sector=24249020472 Oct 12 22:06:27 Tower2 kernel: ata3: EH complete There were about 9 such sections, with a total of 1351 md read errors showing up on the main UI screen. SMART showed NO pending or actual reallocated sectors having cropped up. I then proceeded to run an extended SMART test which took almost 24h, during which the Raw_Read_Error_Rate hit its threshold (001). You could see the SMART attribute steadily diminishing over the whole of the run from the Unraid page for the disk's SMART attributes. 1 Raw_Read_Error_Rate PO-R-- 001 001 001 NOW 8225 I assume that since these errors were occurring (continuing to occur) internally during a SMART extended test, this would rule out issues related to the cabling or controller card(s). Since the tower was still booted (same boot), I decided to try a dd test to see if I would get failures. dd if=/dev/sdb of=/dev/null status=progress Sure enough, not long into the run, there were plenty of read-rate stalls and entries like this in syslog: Oct 14 06:42:35 Tower2 kernel: ata3.00: exception Emask 0x0 SAct 0x80080 SErr 0x0 action 0x0 Oct 14 06:42:35 Tower2 kernel: ata3.00: irq_stat 0x40000008 Oct 14 06:42:35 Tower2 kernel: ata3.00: failed command: READ FPDMA QUEUED Oct 14 06:42:35 Tower2 kernel: ata3.00: cmd 60/00:98:08:b1:ca/01:00:0d:00:00/40 tag 19 ncq dma 131072 in Oct 14 06:42:35 Tower2 kernel: res 43/40:08:00:b2:ca/00:00:0d:00:00/40 Emask 0x409 (media error) <F> Oct 14 06:42:35 Tower2 kernel: ata3.00: status: { DRDY SENSE ERR } Oct 14 06:42:35 Tower2 kernel: ata3.00: error: { UNC } Oct 14 06:42:35 Tower2 kernel: ata3.00: configured for UDMA/133 Oct 14 06:42:35 Tower2 kernel: sd 4:0:0:0: [sdb] tag#19 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=DRIVER_OK cmd_age=17s Oct 14 06:42:35 Tower2 kernel: sd 4:0:0:0: [sdb] tag#19 Sense Key : 0x3 [current] Oct 14 06:42:35 Tower2 kernel: sd 4:0:0:0: [sdb] tag#19 ASC=0x11 ASCQ=0x4 Oct 14 06:42:35 Tower2 kernel: sd 4:0:0:0: [sdb] tag#19 CDB: opcode=0x88 88 00 00 00 00 00 0d ca b1 08 00 00 01 00 00 00 Oct 14 06:42:35 Tower2 kernel: I/O error, dev sdb, sector 231387648 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 2 Similarly, new failed "READ FDPMA QUEUED" entries appeared in the device's own internal SMART history/log. At this point, I was prepared to swap out the drive, however I rebooted the array just to see what would happen. After rebooting, the SMART Raw_Read_Error_Rate had returned to 100 (expected). I re-ran the 'dd' test to see if errors were still happening. NOTHING failed or flaked out. I BELIEVE that all of these read 'errors' were in fact "recoverable" - i.e. the file move operations that succeeded were all able to read and verify the data eventually. I'm currently running some CRC checks on the files I moved, but so far all reads are good (no ATA-level exceptions) and no CRC mismatches have been detected. I'm at a loss to explain why the disk would have exhibited this read-failure behaviour during one boot, and it having disappeared at the next boot. I've never had issues with this disk previously either. Can anybody offer any insights or similar experiences? I'm going to leave the parity drive in-place for now and just keep monitoring it in case this happens again, but for now it seems to have returned to full health?!

ok thanks - just thought I'd ask thanks for Unraid!! happy long-time user

was just upgrading a disk in my array (6TB -> 14TB) - given that the new (larger) disk was pre-cleared, should it be possible for Unraid to detect this and short-circuit writing any data higher than the old (smaller) disk size once it reconstructs that much of it? (given that the remainder is known to be 0-filled and have no impact on existing parity?)

yeah, it's what I said above... I guess my MD1510/LI unRAID server (or at least its graphics output) uses a VGA mode by default that doesn't play nicely with the cheap VGA-HDMI adapter I have (apparently not all adapters are created equal, and they don't work with all possible VGA modes) so the solution was to add/change (e.g.) "vga=6" (and ONLY add that) to the syslinux configuration (kernel boot options) I don't have it in front of me right now, but it is editable within the web GUI i.e.: https://wiki.unraid.net/Articles/Getting_Started#Boot_Mode_Selector_.28Syslinux.29:~:text=clicking on the flash drive on the Main tab within the Management interface and using the Syslinux Configuration section on the resulting dialog. ---- to find ALL the available modes (and what the numbers represent) and debug further, you really need to hookup a REAL VGA-input-capable monitor so you can play around with it (set "vga=ask" and get a list of all the supported modes), then it's trial and error back with your HDMI monitor gory details here: https://www.kernel.org/doc/Documentation/admin-guide/kernel-parameters.txt https://www.kernel.org/doc/Documentation/svga.txt but hopefully "vga=6" will just work for you

Perfect, thanks.

I've been working my way through the procedure to convert all the drives in my array from ReiserFS to XFS. https://wiki.unraid.net/File_System_Conversion#Mirroring_procedure_to_convert_drives I have one question about the end of the process, now that my logical disk numbers no longer match their physical (slot) positions in my array. Can I simply logically re-order ALL of my disks at the end to match the physical positions i.e. via - tools->new config, preserve all - re-order all disks via Main page - re-start via "Parity is already valid" + START I have a single parity drive, which I understand has been critical to the process of reordering drives throughout the process. I just want to confirm I can do 1 single mega-reorg at the end to align my logical/physical numbering. Thanks.

hmm, I think I used rsync -rcvPX by mistake fixed now...

I'm using Unraid 6.9.2 in case that's relevant/helpful

anybody got any experience with this? I'm using the protected-parity "Mirroring procedure to convert drives" - in order to (slowly) migrate my drives from reiserFS to xfs https://wiki.unraid.net/File_System_Conversion#Mirroring_procedure_to_convert_drives the main part of which involves the command: % rsync -avPX /mnt/<disksrc> /mnt/<diskdst> things went OK on the first disk I migrated. but for some reason a few days later when I repeated the process on the 2nd migration (reiserFS -> blank xfs), AFTER the rsync had finished, the files on the xfs disk all had contemporary timestamps (from the time period of the file copy) rather than the original/source file dates has anybody seen anything like this before? it's too late for me to try now, but would re-running the rsync command in that case have been a worthwhile thing to try? (presumably it would copy nothing, but maybe it would fix-up the timestamp info?)

I found that I can add/change the vga=<x> in the syslinux.cfg (following this info https://wiki.unraid.net/Boot_Codes) I got a table of values by booting and hooking up my old VGA monitor and setting vga=ask By experiment, vga=6 (VGA 80x60 TEXT) mode seems to work, whereas vga=extended (VGA 80x50 TEXT) mode and vga=normal (VGA 80x25 TEXT) mode does not... Also found that vga=0x318 (VESA 1024x768x32) also seems to work. Gave up playing for now. It's all quite confusing - not quite sure why some modes work with the VGA-HDMI adapter and some just don't.

Hi, I have an older original Limetech MD-1510/LI tower (VGA - IGP - output only) - and I recently upgraded my monitor but it doesn't have a VGA input. I don't normally use the VGA output of my tower, BUT on the rare occasion where console debugging is required, I like to have that facility available. I recently got a VGA to HDMI adapter/converter (has VGA input + powered via micro-USB, with HDMI output) in the hopes of being able to hook up an HDMI cable to my tower as needed. Unfortunately, I ONLY see the POST screen/text before the output goes blank. I know there IS VGA output there because I dragged an old monitor out of the basement and hooked it up and see the text login prompt. I also know the VGA adapter is working OK otherwise as I hooked it up to an old laptop with VGA output and it seems to be showing a Windows 7 login screen just fine. Can it be that the "normal" VGA output (after POST) from the MD-1510/LI is some kind of unsupported VGA mode that the adapter doesn't recognize/play-nicely-with? Is there any way to debug this or somehow adjust the VGA mode that the MD-1510/LI is using? NOTE - as an experiment, I tried booting the tower into the GUI mode instead of the regular console mode - the VGA adapter is working OK in that mode too... Any advice welcome, thanks.

ok then, will ignore (no other signs of disk/device errors/issues - and the vmstat and /proc/diskstats info seems appropriate for BOTH data drives, despite the GUI) thanks to all for the feedback

Yeah speed mode looks appropriate: it's just the read/write totals/count display that's inconsistent (dare I say wrong?) thanks