magic144

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?)

I for one would also appreciate a "101" summary write-up on the significance of ZFS - particularly with regard to this comment from the 6.12.0-rc1 blog: Does this new feature mean that Unraid will achieve some sort of "silent corruption" resilience through the deployment/adoption of ZFS? (And how does such a facility impact capacity - presumably it's a tunable thing??) I don't know enough practically anything about ZFS to be able to get a feel for this, and it's hard to find this level of info in here. Thanks in advance to any kind souls willing to expand on this.

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

vmstat -d appears to show plenty going on for both sdc and sdd (data drive reads) and sdb (parity drive writes) root@Tower2:~# vmstat -d disk- ------------reads------------ ------------writes----------- -----IO------ total merged sectors ms total merged sectors ms cur sec loop0 127 0 7578 515 0 0 0 0 0 0 loop1 42 0 690 168 0 0 0 0 0 0 loop2 0 0 0 0 0 0 0 0 0 0 loop3 0 0 0 0 0 0 0 0 0 0 loop4 0 0 0 0 0 0 0 0 0 0 loop5 0 0 0 0 0 0 0 0 0 0 loop6 0 0 0 0 0 0 0 0 0 0 loop7 0 0 0 0 0 0 0 0 0 0 sda 984 13946 98646 4437 89 1 1811 313 0 2 sdc 20697540 1288320655 10472145394 562282684 4 0 4 93 0 34932 sdd 20697457 1288320441 10472152197 148281605 4 0 4 108 0 28604 sdb 676 0 24398 1260 20685562 1288330609 10472129324 15762343 0 27455 md1 62 0 2194 0 0 0 0 0 0 0 md2 62 0 2194 0 0 0 0 0 0 0 so I'm wondering if it's just a GUI/display/presentation issue

tower2-diagnostics-20220113-0715.zip as requested, thanks

curious to know... I'm setting up a new system - just pre-cleared (via plugin) my 10TB drive, then installed 2x 6TB drives previously used from the shelf I configured the 10TB as parity, and the 2x 6TB drives as data, then started parity sync. I'm wondering why, from the ongoing stats, that reads and writes only appear to involve 2 out of the 3 drives?? (see attached).

I just assume that whatever it was that was parsing the file got brought into unRAID - I believe it originated in unmenu. I don't have unmenu, and I don't have preclear as a plugin, only a standalone script. 🤷‍♂️ myMain original thread

but... the only "non-stock" plugin I have installed is Nerd Tools I guess that functionality has been subsumed into unRAID these days. I'm glad it's there though.

I guess it has to do with this line: # Version 1.10 - create preclear_stat_sdX files (read by myMain) - bjp999 Just seems odd that if the OS itself is reading/parsing these files, why wouldn't the OS promote/make the preclear script/function available?

But does anybody know HOW unRAID seems to know a pre-clear is happening (and its state/progress) on the web GUI main page?

Indeed - I have never personally had a disk fail preclear. It's more a preventative step. Thanks for your own feedback.

Right. Thanks itimpi. Yeah, I'm pretty much exclusively swapping in bigger disks for smaller ones (rebuilding their content), so having a "clear disk" signature isn't important. The "stress-test" aspect is what I'm focusing on. I have seen reference to "badblocks" (with writes) being an "as-useful" (and presumably built-in) alternative in this regard. Any comments on badblocks vs preclear_disk.sh - pluses/minuses ?

Also, what's the most up-to-date "received wisdom" on continuing to use pre-clear (or is there a more contemporary replacement)? I am primarily continuing to use it for the "infant-mortality" detection use-case.

Might be a silly question but... I have been continuing to use an updated/modified preclear_disk.sh (v1.15+deltas) script for the last few years (not a plugin or a docker, the original script). I have manually updated the script myself over the years with the various patches required. I am surprised that when I look at unRAID's MAIN web GUI page (unRAID v6.8.3), it seemingly KNOWS what's going on and reports the pre-clearing operation and progress. Is there some magic built into unRAID to recognize the pre-clear procedure? How is this reported/known to unRAID? Thanks for any answers.

Yup. I've been using it successfully on 6.3.5. It's a shame it's not officially maintained or incorporated into unRAID itself. Still I've always had issues with the plugin (and it sounds like they might even be exacerbated by 6.4.0) but the script just keeps on working (when keeping up with the patches!) Thanks for the feedback. Good to be sure about these things before taking the plunge