bidmead

After a long break from Unraid I've finally caught up with soon™ and installed Unraid 7.0. Having removed the single 2GB USB drive that in version 6 was having to act as a placeholder for the Unraid array, I can now set my number of Unraid array drives to zero. I'm finding it odd, though, that I still have to power up this non-existent array in order to run dockers and so forth. I haven't yet investigated where dockers will now be installed by default, if not on the array with no drives. Anybody got practical knowledge of this?

Yes, back for me too. The moral is, it's usually you not them. But if it might be them, don't be in hurry to rush in with a fix (particularly if you don't understand the problem!). -- Chris

I'm experiencing exactly this problem. It's only the Apps tab that reports "Browser failed to communicate with Unraid server". This evidently isn't the case, as other tabs are in communication with the server.* The subheading below this reports, more accurately (but unhelpfully): "For unknown reasons, your browser was unable to communicate with Community Applications running on your server." For now, I'm going to assume this is a Community Applications problem and hold off messing about at this end, hoping a fix comes through. (*Oh, wait. "Unraid server" here probably means Lime Technology's server, not my NAS. So the statement may be accurate.) Unraid 6.12.10 -- Chris

Tested Technology has posted part 1 of its review of Unraid on the LincStation N1. Comments, here or on the Tested Technology Web site, would be very welcome indeed. -- Chris

Thanks for the steer, @JonathanM. Categorising the parity-protected array as another kind of user-defined pool makes a lot of sense. Meanwhile I'm following your advice (and Spencer's) with a dummy 4GB USB stick standing in for the conventional disk1 array. -- Chris

I need to correct myself here. I've returned to Unraid after an absence of a couple of years following a hardware failure, and haven't yet got my head around some of the newer developments. I had assumed that ZFS, XFS and BTRFS pools, not forming part of the main Unraid array, would be categorised as "unassigned devices". I've since learned that this binary categorisation is wrong: there's a third category of "user-defined pools", to which these newer storage formats belong. This makes nonsense of my response to @JonathanM, so my apologies are due. Let me rally my thoughts and see if I can straighten out what I was trying to say, which I think remains valid: The core idea of a parity protected array depends entirely on the ability of a dedicated parity-maintaining device (comprising one or two drives) to track bit switching in close to real time as new data are written to any of the several other drives comprising the array. Hard drives are well designed to do this, at their own pace. Solid state devices using NAND can emulate this, and probably with impressive speed. However, although the SSD controller can comfortably write a zero bit into a cell that previously stored a one, it has to copy out an entire block of data to a new set of cells if it's required to overwrite a zero with a one. This elaborate choreography leaves wastelands of out-dated data that will need to be TRIMmed by the operating system from time to time. Copying an entire block that subsequently has to be erased by a high voltage before it can be reused, just to accommodate a single bit-flip, accelerates wear and significantly shortens the life of the device. So while SSDs are valuable for storing chunks of data in normal use, they are not a worthy technology for bit-by-bit parity matching. This suggests that Unraid implemented on an all-solid-state NAS should not employ the traditional parity-checked main array. Instead, its data will optimally be stored in one or more user-defined pools. Very likely these pools will employ RAID configurations. That's my thinking. In attempting to express it as clearly as possible I notice I've fallen into a tone that sounds authoritative. This is spurious. As I say, I'm still trying to get to grips with all this and there's lots of room for me to be wrong. Please straighten me out as appropriate. -- Chris

Thanks, @Kilrah. But I'd suggest that the "most people" argument here demonstrates its usual weakness. UnRAID itself isn't designed for "most people". And the Linkstation N1 is certainly not designed for spinning rust users. Lime Technologies choosing to tie in with this device appears to signal that it's looking to evolve UnRAID to properly include all-SSD NASes. That's not to say there's any thought of abandoning HDs and the parity-protected array for which HDs are well-suited. But with the N1, Lime is taking on the challenge of SSDs. These storage devices can, as you suggest, be kluged into a conventional UnRAID main array, but they don't bit-flip at all well and engineers wince at the idea. -- Chris

Apologies for not being clear. I was suggesting that the parity solution for which spinning rust is well-suited won't be useful for all-solid-state NAS devices, which will instead have to rely on RAID-based storage pool solutions on unassigned devices. The recommendation about unassigned drives you mention seems to me to refer to their use in current conventional HD-based UnRAID configurations. It appears that solid state storage will change that, particularly in future versions of the operating system that make the main (optionally parity-protected) array itself an option. > Why should the name Unraid be an issue? In which case the name "UnRAID" might be thought to be inappropriate. -- Chris

@JonathanM, this question seems to me to be crucial. If I understand the problem correctly, there's an essential mismatch between the (great) idea of a parity checking hard drive (or drive pair) that is responsible for looking after changes of data on an array of drives and the way an SSD drive works. While spinning rust can without too much contortion be thought of as capable of (re)writing single parity bits one at a time, the same process on an SSD is much more of a palaver. The picture I'm getting is of a future all-SSD NAS that uses only unassigned drives pooled using conventional Linux storage techniques (which are, of course, RAID-based).* All the other good UnRAID stuff (readily installable docker apps and so on maintained by a vibrant community) should continue to thrive. But what happens to the name "UnRAID"? -- Chris * LATER: Foolish error on my part. These pools are categorised as "user-defined pools", not "unassigned drives".

Thanks, trurl. No, it's unpingable and its address is unknown on the network. I've rebooted it several times, with and without the UnRAID boot USB. Without the UnRAID USB it should boot into QTS as the original DOM is still in place. However, it doesn't – all eight drive lights are red, I'm getting nothing over HDMI and the built-in display is stuck at SYSTEM BOOTING… As it won't boot into either UnRAID or QTS, it's looking very much as if we have a QNAP hardware failure. But I'd welcome any further suggestions. -- Chris

I tried to log in today to my UnRAID 8-bay server based on a QNAP TS-853 Pro which has been running flawlessly for several months. I was unable to find it at its usual IP address even after a reboot. As far as I can make out, the Ethernet port is flashing normally and the connection to my switch is secure. I've tested the UnRAID boot USB in a second machine and it boots apparently correctly into UnRAID with the static IP address I'd allocated. I'd welcome any suggestion on how to go about diagnosing this further. Please let me know if any further details would be useful here. -- Chris

My problem with calibre on UnRAID is that the webGUI is completely intractable when accessed from a phone. While the regular UnRAID webGUI can be zoomed and panned, calibre's simply fails to shift, making it impossible to access necessary parts of the screen. Has anyone found a workaround for this? -- Chris

Good question, @John_M. It's all set out in the UnRAID story. The SSD in question uses RAISE and I did ask the forum earlier whether this made an external TRIM utility redundant but the response seemed to be to go ahead with TRIM anyway. I still have my doubts about whether the combination of btrfs, TRIM and RAISE may not be asking for trouble. I understand that OWC, the manufacturer, is currently investigating this. Meanwhile, I'm running the SSD, now happily formatted as xfs. TRIMmed weekly, uneventfully. -- Chris

I've raised a query with the vendor about this, @JorgeB. I'm continuing to run the cache xfs-formatted with a weekly TRIM. I'll report back here if I find out more. -- Chris

Thanks for that, @JorgeB This was the other error being thrown up. Can we be sure it wasn't the result of a TRIM conflict? -- Chris