bidmead
-
Posts
120 -
Joined
-
Last visited
Content Type
Profiles
Forums
Downloads
Store
Gallery
Bug Reports
Documentation
Landing
Posts posted by bidmead
-
-
You're right, jonathanm. The drive is still marked as emulated. So what the green message is saying is "There are no read errors because I haven't actually read the disk. And if I do read the disk, I'll be reading the emulation, which by definition, won't have any read errors."
So the question arising from this is how do we get the array to acknowledge the physical drive and use that instead of the emulation?
--
Chris
-
OK, I said I'd try a clean rerun of this without a) the senior moment about which drives are where and b) my misunderstanding of when you can hot-swap. This is that clean rerun.
1. I start with an entirely sane array. It's running but I then pull the Maxstor, simulating a sudden drive failure.
2. UnRAID flags the failure and straightaway goes into emulation mode. In this mode I'm able from my Hackintosh to tap into the (emulated) Maxtor share, use VeraCrypt to mount the encrypted disk image therein and play any of the multimedia files it contains. No buffering or glitches. Exactly as if the Maxtor were present.
3. The big mistake I made last time (I believe) was to plug the drive back in with the array still running. This appears to confuse UnRAID and it keeps using the emulated drive instead of the real one. This time I spun down the array before reinserting the drive. With the array spun down, UnRAID appears to recognise the returned drive almost immediately. I'm not clear how it does this. Is there a checksum of the whole drive somewhere on the Maxtor that corresponds to a checksum retained by the parity drive?
What I've learnt here is that, yes, you can pull a drive while the array is running without affecting services across the LAN to client devices. But it's a good idea (probably mandatory) to spin down the array before returning the drive. And I'm assuming that if your hardware supports hot-swapping you should be able to follow all the similar procedures suggested in the manual but WITHOUT having to power down the machine. But do spin down the array.
--
Chris
-
11 hours ago, jonathanm said:
I'd recommend using the last 4 digits of the serial number for the drive, since the serial number is how Unraid keeps track of assignments.
This suggests to me that I should be able physically to stick these drives into any position in the 8-bay (remembering to spin down the array first) and UnRAID will carry on regardless. Is this the case?
--
Chris
-
Thanks once again.
--
Chris
-
1
-
-
You're right, jonathanm. With the Maxtor reinserted I did create an empty folder on the emulated drive in the hope that this would wake UnRAID up to the realisation that the drive was physically present. That idea didn't work and I think I now understand why.
So, yes, the data on the emulated drive would now be different from the data on the physical drive. And, as you've predicted, what we're getting now isn't just a parity check, it's a Parity Sync / Data Rebuild. Currently at 40%---thank heavens this old Maxtor (circa 2009) is small.
For my re-run I'll make sure a) only to pull and plug drives when the array is down and b) not to change the data on the emulated drive while Maxtor has left the building. Would I be wrong in that case to expect as smooth return to the status quo (no parity activity or rebuilding) when Maxtor makes his come-back?
I'm truly grateful to you guys for sharing my pain here and steering me back to sanity.
--
Chris
-
I couldn't do much with maintenance mode. But now I know not to pull or plug drives while the array is running I think I've managed to re-establish the status quo. What seems to work is:
1. Shut down the array.
2. Pull the drive that claims to be emulated.
3. Start the array. The drive slot is now declared unassigned.
5. Use the pull-down to find the Maxtor and load that back into the slot.
6. Start the array.
7. Warning message: Drive not ready. Content being reconstructed.
I'm hoping that "reconstructed" is different from "emulated" and that the drive's physical presence is now being acknowledged and some parity checking is going on.
At some later stage I'm going to have to walk this whole sequence through again (Start with a solid array, pull a drive, check the emulation, replace the drive) to understand how it's meant to work. My grievous error (apart from my gross misreporting of which drives were where---apologies once again) was not grokking that UnRAID doesn't support drives being plugged and pulled while the array is running.
Yes, it's parity syncing now and the physical presence of the drive has deffo been acknowledged.
What I'm headed for next is replacing this small Maxtor with a much bigger drive and getting the Maxtor emulation pasted onto the new drive. But I'm going to run this pull, emulate, replace once more first.
Oh, and I'm marking the drives externally so I won't get them mixed up again!
--
Chris
-
You're right, but that seems to be a bit extreme. After all the data on the physical drive is identical to the emulated data for that drive. I can see that "rebuilding" would leave us in the right place but I would expect the system simply to be able to say, Oh, hello, you're back again. I'll stop emulating.
--
Chris
-
Thanks, itimpi. Yes, I'd seen that page but couldn't find anything specific there about reinstating a physical drive that has been emulated. I fancy giving maintenence mode a go to see what I can do with that. Worse case, I suppose, I should be able to delete the emulated drive and rebuild parity all over again.
--
Chris
-
Yes, that's right. The parity drive is an 18TB Exos.
*>>embarrassment<<* Ah, wait. Oh, sorry, guys---I clearly have no idea what I'm doing. UnRAID is exactly right and I'm totally wrong. The Exos drive has been sitting here on my desk all along. I pulled what I thought was the unassigned 18TB IronWolf Pro to photograph it. But somehow it's the Exos.
I plead senility. And apologise to trurl and itimpi for wasting their time. Still, we've all learnt something. Me, that UnRAID is semi-hotswappable but you'd better know where those drives are going, and trurl and itimpi that bidmead may well be past his sell-by date.
LATER THAT SAME AFTERNOON
The drives are all back in their right places and the array is now running. The main lesson I've learnt here is that UnRAID groks UnRAID far better than I do at the moment. But with its help and the help of you good guys in the community (assuming you're still speaking to me) I'm on track to learn more.
It only remains to clear up the issue with the Maxtor drive, which I'd previously pulled to investigate emulation during absence (which worked very impressively. I'd created a Veracrypt disk image on it which mounted easily with the drive absent and decrypted on the fly and played its multimedia content flawlessly).
The Maxstor is now back in place, but UnRAID still thinks it has to emulate it and it's marked as such. I'm wondering how I can help UnRAID appreciate that this drive really has come home. The hardware assures me that its powered, but there's no evidence of disk activity.
--
Chris
-
Further info: It seems that a second 18TB data drive that was previously unassigned but that I'd precleared in preparation for adding to the array as another data drive is now turning up in place of the parity drive. The real parity drive is nowhere to be seen on the system even though it hasn't been physically moved.
So apparently I need to find a way for UnRAID to find this parity drive and then reassign it to parity slot 1. And then unassign that second 18TB data drive. The first 18TB data drive is recognised in its correct place as Disk 1 and greenballed.
I can visualise an instinctive path forward through this but I'm happy to wait for solid info from folks who know. Indeed, it was an instinctive path forward that got me into this start error mess...
--
Chris
-
Thanks, trurl. I hope this is what you're asking for.
The drives don't turn up under Historic or unassigned. They're on the Dashboard as offline but healthy. Help would be much appreciated.
--
Chris
-
Ah, interesting development here. It seems you can't apply to extend the trial while the array is still running. I've stopped the array and have successfully extended the trial, apparently---registration says I now have 14 days remaining.
However...
I can no longer restart the array. Every (many) times I've tried I get the message: Array stopped: start error.
According to the log there are "too many missing disks". The disks I've been using, however, including the parity disk, are all installed and lit up.
Worst case: I'd be happy to start afresh. But I'm not clear how to factory reset UnRAID. Any ideas on what best to do next would be welcome.
--
Chris
-
8 minutes ago, itimpi said:
You probably do not need to power down, but Unraid is not hot-swap aware and it will not let you change any Disk assignments with the array started.
As I've just discovered. Thanks. Yes, the problem is that the WebGUI MAIN page you need to do the necessary reassignment is only available when the array is spun down. This strikes me as design logic that might be improvable in future versions of UnRAID, unless there's a good reason why UnRAID can't handle full hotswapping.
I was keen to avoid spin-down as I'm at the end of my UnRAID trial period, awaiting my registration code. But I suppose this is a good opportunity to try out the trial extension scheme.
--
Chris
-
Is there any reason why the array needs to be taken down and the server powered down in a hot-swap capable device? Can I not simply remove the old drive and replace it with the new drive while the array is still running?
--
Chris
-
Interesting question (I think so, anyway). I have an UnRAID drive flagged to spin down after 15mins of neglect. It's shared over the LAN. When I access this sleeping drive in the normal way over the LAN the drive obligingly spins up.
However, I've created a Veracrypt disk image on this drive, mounted it with Veracrypt on my Hackintosh, where it appears as a regular remote share---when the drive is spinning. All the encrypted files inside the disk image can be accessed just as if they were on a regular remote share.
If I leave the UnRAID drive to spin down, the contents of the Veracrypt disk image all still appear in the Finder, as you'd expect. You might also expect, as I did, that an attempt to access this content, by playing a movie found inside the disk image, for instance, would spin up the drive.
This appears not to happen, though. The UnRAID share seems unaware that I'm trying to access it. It turns out that I need either to touch the drive OUTSIDE the disk image (by creating a folder there, perhaps) or explicitly spin up the drive from the UnRAID WebGUI.
I'd very much welcome comments and explanations.
UnRAID version 6.8.3
--
Chris
-
Much appreciated, Cessquill. There's a lot of stale news knocking around the Internet (some of it undated, I'm horrified to discover). Very happy to be corrected on this.
--
Chris
-
Got it. Excellent point, Constructor trurl. Thanks.
Formatting a drive entails laying data down on it and if UnRAID sees data on a new drive (as I understand it) it will decide it needs clearing when that drive asks to join the array.
But if the formatting of a precleared drive is left to UnRAID, only those bits on the parity drive corresponding to the formatting it lays down will need to be checked and/or flipped. And UnRAID will be taking care of the parity in parallel with the formatting operation. Is that about right?
If so, only the parity drive and the newly added drive need to be spinning, as UnRAID already knows the parity status of all the other drives in the array.
Bottom line: PreClear, add the drive to the array, then format the drive. This is important, as:
1. When UnRAID is clearing a drive the array has to be down and can do no work.
2. Today's multi-terabyte drives can take 24 hours or longer to be cleared.
(Sanity check invited. I'm very new to all this.)
--
Chris
-
Got it, JorgeB. Your real-time responses very much appreciated. Many thanks for your help.
--
Chris
-
13 minutes ago, JorgeB said:
You need to format it, next to array start/stop button.
I feel we're nearly there, but I remain defeated by my ignorance. On my WebGUI Dashboard, the icon next to the array start/stop button does a reboot.
--
Chris
-
Thanks again, JorgeB. That's really helpful.
OK, I've now set the Maxstor format to btrfs and successfully added it to the restarted array.
More confusion here, though, as under Main, the drive file system is reported as btrfs but is also being reported as "unmountable, no file system".
Apologies for the repeated requests for handholding. The UnRAID WebGUI is magnificently detailed and the clarity of the physical layout is exemplary (QNAP and Synology please note). But the logic is occasionally defeating me.
--
Chris
-
In the screenshot I posted.
--
Chris
Sent from my CPH1907 using Tapatalk -
Ah, OK. Thanks, JorgeB. That makes sense. If I'm going to add the drive to the array (which is my intention) I don't need to format it at this point because the act of adding it will present the formatting opportunity.
What I'm less sure about it why the drive is being declared as "missing". As a complete newbie I'm not clear what UnRAID thinks this drive is missing from. Not missing from the array, because it was never in the array. And not missing from the list of unassigned devices because it's still showing up in that list.
Can you clear this up for me?
--
Chris
-
Thanks for getting back to me.
Ok, I've done what you suggested. The red X disappears and I've refreshed the browser page. But there's no change. The format button is still greyed out and the drive still appears as both unassigned and missing.
I intended to add the drive to the array.
--
Chris
Sent from my CPH1907 using Tapatalk -
OK, I've used the Preclear plugin successfully to preclear a 300GB Maxtor drive. The precleared drive shows up under Unassigned devices. There's a button to format it, but it's grey and has lost its link. Below is a list of Missing drives and the Maxtor appears there.
Can anyone tell me what's going on here?
--
Chris
Best pratice to replace a still working data drive with a larger one?
in General Support
Posted · Edited by bidmead
additional explanation and further thoughts
So we're saying the rebuild is mandatory. That seems to be a real shame.
OK, I'm going to spin down the array, leave the drives physically where they are. Then restart the array in maintenance mode, unassign the drive from the Disk 2 slot. Then spin down the array, reassign the same drive to that slot and spin the array up again.
It should then rebuild?
I see "Replacement disk installed", which does suggest a rebuild is being triggered.
And indeed...
But this rebuilding of a perfectly good drive seems to me suboptimal. Is there really no user intervention that can say, trust this drive until the next scheduled parity check*? I assume a workaround would be to leave it as an unassigned drive and share it out from there.
Any views on this?
(*I guess the problem might be that if the reinserted drive is accepted into the array on trust as I suggest, it's not just the integrity of that drive that's at stake. The parity check across all the drives is in jeopardy.)
--
Chris