Pumped Posted February 27 Share Posted February 27 (edited) Hi all, I ran into an issue with a disk today. It would not mount and found the drive being emulated. After some troubleshooting I found the issue was not the drive itself but the SATA port being used. After switching ports the drive appeared but did not mount in it's usual place. The device is showing up in unassigned devices, where I am able to mount it and can see the data. Edit: Disk 6 has an error saying "Device is missing. Contents emulated." The unassigned device mentioned above is the exact device that was working in the array yesterday. If I try and assign the device to Disk 6 (where it was previously) it is being treated as a new device. Is there a way to assign the device without triggering a rebuild of the parity and the device? tower-diagnostics-20240228-1019.zip Edited February 28 by Pumped Quote Link to comment
Squid Posted February 28 Share Posted February 28 Drives get redballed when a write to it fails. Since this did happen and/or a write to the emulated drive happened while the disk was missing, the contents between the emulated and the physical drive do differ, if only slightly. I always recommend to let the drive be rebuilt so that everything is all in sync. BUT, to do it without rebuilding you would do a Tools, New Config, keep all of the assignments and when starting the array check off that Parity is already valid. But you should really after that do an immediate parity check to make sure everything is back synced together. IE: Best bet is to simply rebuild onto the drive itself. Quote Link to comment
trurl Posted February 28 Share Posted February 28 Mounting the physical drive with Unassigned Devices would make it even more slightly out-of-sync unless it was mounted read-only. If you don't rebuild it, any emulated writes to the disk will be lost. And at the very least, the failed write that disabled the disk was emulated. If you don't know the exact instant it was disabled and that no further writes intended for the disk was done, then probably additional emulated writes happened. 19 minutes ago, Squid said: Best bet is to simply rebuild onto the drive itself. Rebuild won't take any longer than the parity check you need to do if you don't rebuild. And it isn't really parity that is out-of-sync, it is the data disk. Quote Link to comment
trurl Posted February 28 Share Posted February 28 3 hours ago, Pumped said: without triggering a rebuild of the parity and the device? It won't rebuild parity (and won't need to) if you rebuild the data disk. The whole point is that the data disk doesn't match parity. Parity is correct, assuming you don't force the array to accept the out-of-sync contents of the data disk. Quote Link to comment
Pumped Posted February 28 Author Share Posted February 28 Thanks @Squid and @trurl, I ended up rebuilding the data drive. It was either that or the parity and I think I preferred the idea of rebuilding the data. Cheers Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.