unRAID Server Release 6.2.0-rc3 Available


Recommended Posts

Tom, can you or anyone else confirm if this behavior is normal or expected?

 

On this thread a user is running xfs_repair on a disable disk, user already assigned a replacement disk assigned but it's not rebuilt yet, he's using v6.1.9 but I just tested on 6.2rc3 and it's the same.

 

Running xfs_repair on a disable disk with no disk assigned results in reads from all other disks while it's searching for a secondary superblock, as expected, but running it on a disable disk with an assigned but not yet rebuilt disk results also in writes to this disk, I don't understand what is being written to the disk, if nothing else it really slows down the superblock search.

 

Just did a quick test on my test server using a small SSD, running xfs_repair on a emulated disk with no disk assigned took 3 minutes, with an assigned disk same check took 13 minutes.

An "assigned but not yet rebuilt disk" with array Started (in order to do xfs_repair) can only result if the data-rebuild of that disk was Canceled - is that how it's in this state?  When array is started and there exists a replaced disk (which would ordinarily be target of a rebuild) driver does not distinguish whether or not a rebuild is actually in progress - it just always uses on-the-fly parity reconstruct to read data, and writes target device (as well as parity) for writes.

 

Looking at that thread, if user has 'rebuilt' onto a spare disk, and critical to get data off, then it might be helpful to unassign the disk and do an xfs_repair on partition 1 outside the array, ie, target would be '/dev/sdX1' (replace X with proper device identifier).  If this works then mount manually, eg, 'mkdir /x ; mount /dev/sdX1 /x' and look at file system.  If it looks ok then use 'new config' utility to clear assignments, then add disk back into array, recreate parity.  Make sense?

Link to comment
  • Replies 190
  • Created
  • Last Reply

Top Posters In This Topic

An "assigned but not yet rebuilt disk" with array Started (in order to do xfs_repair) can only result if the data-rebuild of that disk was Canceled - is that how it's in this state?  When array is started and there exists a replaced disk (which would ordinarily be target of a rebuild) driver does not distinguish whether or not a rebuild is actually in progress - it just always uses on-the-fly parity reconstruct to read data, and writes target device (as well as parity) for writes.

 

Start with a stopped array with a disable and unassigned disk, assign a disk to the disable slot and start the array in maintenance mode in order to run xfs_repair, a rebuild doesn't start, if you then run xfs_repair on the disable disk that's when it begins writing to it, in this example, md2.

Screenshot_2016-08-14_20_00_20.png.7aab22eb8248f35ad7e5f54f5252f12e.png

Screenshot_2016-08-14_20_02_56.png.9155582b2824b29271859745a6eacf16.png

Link to comment

Start with a stopped array with a disable and unassigned disk, assign a disk to the disable slot and start the array in maintenance mode in order to run xfs_repair, a rebuild doesn't start, if you then run xfs_repair on the disable disk that's when it begins writing to it, in this example, md2.

 

"Maintenance mode" is not a md/unraid driver state.  It just means md/unraid driver has been started but no array devices have been mounted, and thus no shares exported, etc.

 

Sure I guess we could fix this but this is a rare corner case; ordinarily you would never do this (run xfs_repair on an assigned disabled disk).  If you want to speed up the repair you could unassign the replacement disk.  That would have the exact same effect.

Link to comment

Sure I guess we could fix this but this is a rare corner case; ordinarily you would never do this (run xfs_repair on an assigned disabled disk).  If you want to speed up the repair you could unassign the replacement disk.  That would have the exact same effect.

 

That makes sense, agree there's no point in starting the array like, just wanted to make sure.

Link to comment

Did a fresh install of 6.2 and i have noticed that if I stop and start my Windows 10 VM my system hard locks and requires me to turn off the power to fix. The VM is new and not a carry over.

 

The vm will start find with Unriad but again stopping and start will crash my system.

 

Also I need to expand the size of a vdisk but don't see a way, am i missing something?

diagnostics.zip

Link to comment

After starting xfs_repair on md2:

 

What was odd about the screenshot was that disk2 was showing non-zero write count, and parity was showing zero write count on xfs_repair.  Explanation: first you must have clicked 'Check' without changing the option, which is -n, which means do not write.  That explains why parity writes count was 0.  The reason disk2 has a non-zero write count is that the driver does not distinguish between a read failure on a device due to I/O error vs. due to disk being "invalid" (meaning, in driver, when I/O error occurs disk is marked "invalid" for that I/O, and when we're dealing with a replacement disk, all blocks start out "invalid").  Anyway, when xfs_repair does its reads to check the file system, the md/unraid driver calculates the data using on-the-fly reconstruct.  It then writes the reconstructed data to the target disk (disk2).  This is what you need to have happen if a reconstruct is happening, and as I mentioned earlier driver doesn't take into account whether or reconstruct is active or not in this case (where a disabled disk has been replaced).  Bottom line: it's working correctly and this is a rare corner case.  I guess a side effect is that it slows down the operation because it needs to write two disks (parity and disk2) or three disks (parity, parity2, disk2 - if you have parity2).

Well this was interesting, thanks for posting.

Link to comment

This is what you need to have happen if a reconstruct is happening, and as I mentioned earlier driver doesn't take into account whether or reconstruct is active or not in this case (where a disabled disk has been replaced).  Bottom line: it's working correctly and this is a rare corner case.  I guess a side effect is that it slows down the operation because it needs to write two disks (parity and disk2) or three disks (parity, parity2, disk2 - if you have parity2).

 

That's what I assumed was happening, I don't expect to see this much in the future but it's good to know for sure what's going on, so in case someone does again we can warn them, like the thread I linked xfs_repair had been running for 2+ days for a 4TB disk when it usually takes much less than a day.

Link to comment

I am noticing that my server appears to be suffering from poor network speeds. For example, if I copy a 4GB file off my unRAid server to my mac, it takes 20-22 min, which is crazy for a gigabit based network. To copy the same file from my Mac to another unRAid sever on my network running 6.19 takes less than a minute. Is it possible that the drive implemented in b6.2rc3 for the integrated network card on my Asus P8Z68-V PRO board has issues? This is the info for the built in ethernet card:

 

00:19.0 Ethernet controller [0200]: Intel Corporation 82579V Gigabit Network Connection [8086:1503] (rev 05)

 

Everything shows gigabit, and the server works, but file copies are slow as molasses.

Link to comment

Did a fresh install of 6.2 and i have noticed that if I stop and start my Windows 10 VM my system hard locks and requires me to turn off the power to fix. The VM is new and not a carry over.

 

The vm will start find with Unriad but again stopping and start will crash my system.

 

Also I need to expand the size of a vdisk but don't see a way, am i missing something?

 

Likely related to a device you're passing through to the VM, most likely a GPU.

Does this happen when you remove the GPU from the XML of the VM and start/stop the VM using VNC as the display adapter?

 

This is also not likely specific to RC3, so I'd recommend starting a thread in general support so others can help to troubleshoot the issue, and get more details as needed.

Link to comment

I am noticing that my server appears to be suffering from poor network speeds. For example, if I copy a 4GB file off my unRAid server to my mac, it takes 20-22 min, which is crazy for a gigabit based network. To copy the same file from my Mac to another unRAid sever on my network running 6.19 takes less than a minute. Is it possible that the drive implemented in b6.2rc3 for the integrated network card on my Asus P8Z68-V PRO board has issues? This is the info for the built in ethernet card:

 

00:19.0 Ethernet controller [0200]: Intel Corporation 82579V Gigabit Network Connection [8086:1503] (rev 05)

 

Everything shows gigabit, and the server works, but file copies are slow as molasses.

What do you mean "Everything shows gigabit"? Where do you see that on your server?
Link to comment

Possibly related: I can tell you that if you pass a video card through to a Windows 10 VM, the nic the VM sees is different.

Evidence of that is I can set a static IP on the nic in Windows while set up for VNC and if I switch to a passed through video card, the nic in Windows does not have the static IP. Setting the static IP on the nic reports that another disabled nic has the IP address already assigned to it.

Link to comment

Did a fresh install of 6.2 and i have noticed that if I stop and start my Windows 10 VM my system hard locks and requires me to turn off the power to fix. The VM is new and not a carry over.

 

The vm will start find with Unriad but again stopping and start will crash my system.

 

Also I need to expand the size of a vdisk but don't see a way, am i missing something?

 

Likely related to a device you're passing through to the VM, most likely a GPU.

Does this happen when you remove the GPU from the XML of the VM and start/stop the VM using VNC as the display adapter?

 

This is also not likely specific to RC3, so I'd recommend starting a thread in general support so others can help to troubleshoot the issue, and get more details as needed.

 

Yes I have  a GPU on passthrough but didn't have this problem on 6.1.9 that is why I was bring it up here.

Link to comment
Guest
This topic is now closed to further replies.