bidmead
-
Posts
120 -
Joined
-
Last visited
Content Type
Profiles
Forums
Downloads
Store
Gallery
Bug Reports
Documentation
Landing
Posts posted by bidmead
-
-
SSD TRIM
I'm wondering if it's necessary/desirable/unrecommended to install the SSD TRIM plugin with an SSD that uses RAISE.
--
Chris
-
You're wrong, @Vincenzo, to think that UnRAID makes no provision for drives outside the array. The Unassigned Devices plugin lets you manages such drives and even export them as shares. And the newest version of UnRAID, version 6.9 (currently a release candidate) incorporates unassigned drives more thoroughly into the UnRAID concept without necessarily including them in the parity-protected array. One or more drives can be assembled into pools that behave like single storage devices and can be included in the array or not.
Version 6.9 also seems to be generalising the idea of the cache into a special case of a pool. The cache drive (or pair of cache drives) was never part of the array, never a party to the parity checking. As its name implies, is was a "secret pocket", intervening between the source and the sink to help speed up data transfer (partly by being a super-fast drive and partly by not having to participate in CPU-costly parity checking).
The cache was simply acting as a proxy for a cached share pending the action of The Mover, which steals up in the night (usually) to move files from where they actually are (on the cache) to where the source thought it had sent them (the target share on the secure array).
--
Chris
-
Let me pitch in with the news that I have UnRAID running very nicely on a QNAP TS-853 Pro. With a few caveats (see below).
I used the HDMI-out to switch the BIOS to prefer booting from the UnRAID USB. This meant I could leave the DOM in place. QNAP seems to want me to do this as it's physically secured with a huge blob of glue, although I'm told this can be fairly easily chipped away.
CAVEAT1: No fan control now. Swapping the fans would be a fix, but there's no noise/heat problem that makes this an issue.
CAVEAT2: The 2-line LCD display is stuck on "SYSTEM BOOTING". There's a Github project that might be useful here: https://github.com/bkram/qnapdisplay
CAVEAT3: Shutdown doesn't ever shutdown the machine. It always reboots. I need to look into this but the workaround is to catch the machine just before the reboot and pull the plug. No big deal with a machine with removable drives which seldom needs to be shut down.
CAVEAT4: This is a new one to me, and puzzling. The DOM is (obviously) an unassigned device and I leave it unmounted. As a precaution it's also set as read-only. SO AS IT'S UNMOUNTED, WHY AM I SEEING READS HERE? These reads are incrementing constantly.
UnRAID 6.9.0-rc2
--
Chris
-
What happens then when they overflow? You don't want to have to reboot a NAS just to clear the logs.
Conversely, you may not want to lose the logs when you need to reboot.
I realise all this can be managed manually. But is there an UnRAID tool to handle this?
-
I'm a bit puzzled by this. I'm used to Linux log files automatically archiving themselves at a certain size and also being easily deletable. Are these features not implemented in the UnRAID WebGUI?
--
Chris
-
@Vincenzo: thurl is right when he says "Until you have multiple disks, you don't have RAID of any kind" (except that Synology doesn't think so---they've invented "RAID Basic" as a marketing name for their one-drive hardware!). But (and I speak as one only dipping an early toe into this UnRAID adventure) you can certainly start with a single drive, as I did about a couple of months ago, and add drives later as your budget and inclinations take you.
That single drive won't have any protection except the protection built into the drive. Modern drives actually look after themselves pretty well, and one of the first things you'll start to appreciate about UnRAID is the way it surfaces all the information about the drive's condition. A drive will typically either fail when new or fail when it's getting old (3-5 years, depending on the build quality) and UnRAID guards against that early failure by putting drives through a preliminary "Clear" procedure. Any drive passing that test should be good to go.
If you haven't started with a brand new drive, preferably built to enterprise standards, it's a very good idea to add a parity drive before you get serious with your NAS. But you can learn a lot on the nursery slopes with any old drive (that passes Clear) and a free trial licence. The trial licence gives you a month to find your feet, and a three week extension after that is easily added automatically. After that, the cost of the licence depends on the number of disks in your system, but you probably know about all that already.
So, yes, my advice is definitely not to feel shy about getting stuck in with a single drive. If you've any previous experience of classic RAID (which, IMHO, really has had its day for domestic and SMB use now that drive capacities are in double digit terabytes) you'll be amazed as I am by the flexibility of UnRAID.
--
Chris
-
Like red wine—serve at room temperature.
-
Thanks, itimpi. Yes, you're right---I wasn't fond of calling a pool a cache if it wasn't being used for caching. And right again about "cache only" already being a standard way of handling appdata, domains and isos (effectively taking them off the parity-checked array), which is what I'm doing already.
On that basis, I suppose, calling an out-of-array pool a cache in order to give it individual SMB security, isn't so much of a kluge. And it seems to be the only way to do this, because the method suggested by trurl (which works fine and which I'm now using---thanks, trurl) seems to set user/pass security for ALL unassigned devices, which may not necessarily be what you want to do. Although, I assume one can individually set SMB user/pass to all/no pass on a per share basis (haven't investigated this yet).
It was interesting semantics that when my kluge calls a pool named Maxi a cache set to Cache Only there is actually a cache called Maxi. So the pool is caching on itself. And---if I'm right---setting a pool to be its own cache is so far the only way to apply SMB security to a particular pool without engaging it for the whole set of unassigned devices.
A corollary of this is that UnRAID (now?) seems to allow multiple caches with different names. Or, rather, that a pool called Cache is just a special case of a Pool Device.
And just when I was getting used to the idea of there being two classes of UnRAID devices, array devices and unassigned devices (three, if you count the Boot device), I now find that my one-drive pool called Maxi is neither of these, instead belonging to a new called called Pool.
> If you can think of a better name to refer to them than cache pools feel free to suggest it.
I think 6.9.0 answers this question for us. These things are called Pool Devices
For some reason I'm being flagged here as an "Advanced Member". Please ignore this. Obviously, I'm merely entering the edge of the jungle wielding a toy plastic machete.
--
Chris
-
3 hours ago, trurl said:
Why are you concerned with this?
Quite simply because I don't like kluging when there's a better way of doing something. I gather from your subsequent response that there is. I haven't tested this yet, but thanks.
--
Chris
-
I've exported the whole pool (the single drive) as a user/pass protected share. And that seems to work fine with no issues.
My question is about the apparent need to pretend that this is a cache drive set to Only in order to make it user/pass protected. It isn't caching anything and it isn't, in any sense, part of the array.
However, I notice that my actual cache drive is included in the array drive count. I can follow the logic of this, But because I'm having to pretend that the new pooled drive is also a cache drive, it too gets included in the array count. That seems to me to be, er, counter-intuitive.
So my problem here isn't practical, it's a logical problem that leaves me wondering if I'm kluging around something I could/should be implementing more straightforwardly.
BOTTOM LINE: Am I right in thinking that there's currently no way of exporting an entire unassigned device as a user/pass protected share except under the guise of a cache drive set to Only?
--
Chris
-
Yes, "enable user share assignment" is set to yes for this pool device. I'm not clear if you're saying it shouldn't be necessary also to characterise the pool as a cache device in order to share it across the LAN. Have I added a redundant step?
If so, can you set out here or point me to the procedure for sharing an off-array pool device across the LAN using user-based security?
I'm also not clear what these "copy issues" are that you mention.
--
Chris
-
I've created a single-drive pool, btrfs formatted, and have been trying to work out how to export it as a share. The only way I've been able to do so far is to pretend it's a cache drive and set it to Use Cache Pool Only.
The logic behind this seems to me somewhat contorted. The thing is no kind of cache and I'm left wondering if this is UnRAID's semantics problem or am I simply kluging around something obvious that I'm missing.
--
Chris
-
It seems that unassigned drive encryption has developed since this video from SpaceInvader One. The password's no longer in plain text in a file called keyfile. It's now encrypted in /tmp/unassigned.devices/config/unassigned.devices.cfg. And despite being in /tmp, as far as I can make out the file persists through powercycles. So the data will remain encrypted if someone steals the drive but will autodecrypt if the whole UnRAID server is stolen.
Have I got that right?
--
Chris
-
Actually, the Maxtor story has one last chapter. I don't know if I'm right in continuing it here because it raises a rather different issue. But let's see.
The old Maxtor failed the rebuild, almost certainly due to a bad sector or sectors. However, I understand that the PreClear app can reallocate dud sectors, so I ran the drive through another single-pass total preclear. It passed.
So I've now set it up as I originally intended: it's a luks-btrfs unassigned drive exported as a disk share. It doesn't turn up under Main/Disk Share, I assume because it's not exported from the array. (Is this right?)
The luks-btrfs format was created against a pass phrase which will be required every time the disk is mounted. You can set this drive to auto mount or mount it manually from the WebGUI. To do either of these you need (only once) to enter the pass phrase into Setting/Unassigned Devices/Set Encrypted Disk Password.
Now the share can be loaded with no formality across the LAN. But this isn't, of course, very secure. You really want the share only able to be loaded against a pass phrase. But you can't share the disk until its mounted. And you can't mount it without the pass phrase. So, by definition, once it's a share its not password protected (except against it being stolen, with data access attempted outside the UnRAID device).
Is this how it is, or am I missing something? (I feel I probably am.) If not, then the workaround is clearly to use something like VeraCrypt to create an encrypted disk image on an unencrypted share or drive and require Veracrypt on the client device for the decryption.
--
Chris
-
Just to wind up the Maxstor story, I've successfully replaced that (now failed) drive with the second IronWolf Pro after a rebuild lasting one day, 10 hours, 26 minutes.
The Maxstor data are all preserved and the previous 300GB Maxstor share is available across the LAN. But I've hugely expanded the capacity of the array. I have my green ball back again. Job done.
Many thanks to this forum for the invaluable help.
--
Chris
-
Yes, that makes a lot of sense, trurl. Today's hard drives (especially once they've run the gauntlet of PreClear), it seems to me, are considerably more reliable than the commodity drives that inspired the invention of RAID. And even more reliable, I'd argue, than the costly enterprise drives that RAID aspired to replace. Bigger but fewer makes good sense today.
But I like the idea of having multiple hotswappable bays on an UnRAID system, if only because I can dump unassigned drives in there, test them with PreClear and use them experimentally as shares without having to add them to the array.
--
Chris
-
The catch about migrating ever upwards to these very impressively engineered huge drives is that we begin to run into one of the issues that drove us away from RAID: the rebuild time and the pressure this exerts on the reliability of the other drives in the array.
With UnRAID, I'd have thought, much of the USP is the ability to use a large number of rather smaller drives, recovering from drive failure over a tea-break rather than during a three day vigil. And, particularly, if failing to recover, at least not losing data on the other drives of the array.
--
Chris
-
I pursued the rebuild of the Maxtor drive. But, as we might have expected, the work taxed the dear old drive beyond endurance. It failed the rebuild and UnRAID looped around several times trying the rebuild afresh until I put it out of its misery. I'm now running the rebuild on the second IronWolf Pro, which was always my original intention, to demonstrate that expanding capacity is a lot simpler with UnRAID than with, say, TrueNAS Core.
--
Chris
-
Interesting question, jonathanm, but I may not be the one to answer that. I have 40 years experience as an IT journalist, but only a month's experience of UnRAID.
For what it's worth, it seems to me that "array turned good" was misleading once the physical drive was replaced. After all, what is the change from the previous state, emulating the missing drive, to the present state, emulating the drive but the drive is back in its slot? The goodness quotient hasn't changed: we're still emulating the drive and therefore sacrificing our insurance on all the other drives. The goodness is only restored once the physical drive has been fully successfully rebuilt.
This should surely be a yellow alert, saying something like: Disk 2 emulated, rebuild required.
Bottom line, though: the punter should alway keep an eye on the browser tab icon. If it's not a green ball, action is needed (or maybe ongoing).
--
Chris
-
2 minutes ago, jonathanm said:
Perhaps you could recommend a change in how this is handled, since the experience is fresh?
Recommend to UnRAID management how the reporting of the replaced drive might be better handled? Or recommend to readers (as we certainly shall) that keeping an eye open for errors is crucial for a trustworthy NAS?
--
Chris
-
6 minutes ago, jonathanm said:
Adding 300GB of capacity to 18TB of space hardly seems worth the risk.
Excellent point, of course. But thanks to the small size the rebuild times are short, which is what I need if I'm going to get all this written up before the end of the year. I'm anticipating that the Maxtor will end its days as an unassigned device with a btrfs encrypted file system. Tested Technology is very grateful to Seagate for the donation of these very large drives, but we also want to show readers that UnRAID is good for older, smaller drives too.
I take your point, of course, about failed drives jeopardising the entire array. And an array built entirely from 12 year old drives like this Maxstor would be unreliable. But the combination of UnRAID's clear test, its very explicit surfacing of the SMART data, the opportunity for regular parity checks and the option of running a pair of parity drives, to my (newbie) mind does open up the option to get into UnRAID very economically, mustering a bunch of drives that happen to be lying around to create something non-mission-critical like a multimedia server.
--
Chris
-
And, of course, you can happily insert a drive while the array is running---as long as it's not part of the array.
--
Chris
-
23 minutes ago, bidmead said:
But this rebuilding of a perfectly good drive seems to me suboptimal.
My newbitude is showing through here. We're not just rebuilding the drive, we're rebuilding trust across the entire array.
--
Chris
-
1
-
-
20 minutes ago, trurl said:
Not confused at all. No point in replacing a disk with array started (or even under power) because Unraid won't use it until rebuilt, and it won't begin rebuilding until you assign a disk to the emulated slot.
You will have to stop, unassign the slot, start the array with nothing assigned to the slot, stop, reassign, start to begin rebuilding.
Sorry, trurl, I was late reading this. Yes, that's what I've done. Rebuilding now.
--
Chris
Dynamix - V6 Plugins
in Plugin Support
Posted
I can't run sensors-detect on this 6.9.0 rc 2 UnRAID as there seems to be no perl available. Any suggestions?
--
Chris