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