bidmead

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

Not only is the TRIM utility not useful for btrfs formatted SSDs (because TRIM is built in to btrfs) but it appears to be positively dangerous. My recently destroyed btrfs SSD cache drive was using the UnRAID TRIM utility (on advice from other UnRAID users) and succumbed after a couple of months, turning read-only with the error: cache and super generation don't match, space cache will be invalidated If I'm reading this aright (always a big IF) and the current UnRAID implementation of TRIM is destructive on btrfs-formatted SSDs, shouldn't the utility be updated to detect btrfs, warn the user, and render itself inactive? The good news is that only the btrfs formatting was destroyed. Reformatted as xfs, the SSD lives on. But if I can get confirmation of my assertions here, I'm inclined to return the SSD to btrfs. -- Chris

Thanks for that, @ich777 My jDownloader directory is on a single device, which happens to be the cache drive. I'll investigate deleting the .jar file from the appdata directory and report back. LATER THAT SAME EVENING I seem to be in serious trouble. I tried to get to appdate using krusader but its WebUI is kaput too. So I'm using the krusader console. All I can find in /unraid_shares/appdata/ is syncthing. No sign of any other docker data there. -- Chris

Damn, jDownloader is defeating me again. I got it working when I set the port to one not previously assigned to another docker (always a good idea) and it was running fine. But now VNC is telling me it can't connect to the server and I gather from the logs that I have an invalid or corrupt jdownloader.jar. The only two changes I've made to the config files are to set the port to 18080 and change the local download to mnt/user/jDownloader/ -- Chris

You're spot on, @ich777. The clue was in installation log which was trying to warn me of a port conflict. The default port was already being used by calibre. I've now switched to 18080 and all is well. Many thanks for the valuable lesson. -- Chris

JDownloader has been working marvellously. Until today. Now, when I try to start it I'm seeing: EXECUTION ERROR Server error. I removed the docker and reinstalled it. Same result. Nothing appears to be showing up in the logs. Any advice would be welcome. -- Chris

My Calibre Docker's WebUI now announces itself as "Guacamole Client". I think with previous versions it called itself "Calibre". What can I do to change this? -- Chris

Tagging on here in the hope of responses relevant to this thread: I'm trying to understand UnRAID's FTP service. I notice that there are several FTP dockers available in the Apps Store, although I see from /etc/inetd.conf that UnRAID offers the option to run a choice of two FTP servers (vsftpd and proftpd). What advantages do the dockers offer in this context? -- Chris

Did you take SED any further, @stereobastler? I'm hoping to investigate the possibility of using hdparm to set the password on SED drives, rather than using the BIOS. There's an hdparm parameter, --sanitize-crypto-scramble, that I believe might do the trick, Do you, or anybody else here, know anything about this? -- Chris

@dimes007 Did you take your SED investigation any further? I'm preparing an encryption supplement to the Tested Technology UnRAID story and would welcome any more information. -- Chris

This is a question I've put to memory vendors and never had a satisfactory answer. They just quote the official manufacturer's specs back at me. ===✄=== I have an 8-bay QNAP TS-853 Pro, currently with 4GB of RAM and a Celeron J1900 processor. QNAP and Intel both spec the maximum memory capacity at 8GB. However, it's my understanding that this maximum is derived from the number of memory banks available (2, in this case) and the maximum capacity of a compatible memory module at the time the processor was launched (2013), which was 4GB. Would it be true to say that when 8GB DDR3 SODIMMs became available the maximum became 16GB? I believe that 16GB DDR3 SODIMMs single modules are available too. Do you know if these would be compatible with this QNAP hardware (I'm not using QNAP's QTS operating system)? ===✄=== It's a specific question but I'd like to get to the fundamentals. What exactly is that max RAM spec based on? Is it the case that the number of processor address lines limits the number of banks? And that what limits the size of a bank is down to current manufacturing capability? Anyone? -- Chris

Thanks, @itimpi. I'll follow that through. BTW, I have a Pro licence---I'm not trying to limit my drive count. -- Chris

I've installed UnRAID on a QNAP NAS without opening it up to remove the DOM. I want to ensure that the DOM and its contents remain intact in case I ever want to derepurpose it back to being a QNAP again. The WebUI seems to offer no easy way to hide the DOM from UnRAID so I've marked it as read-only. It occurs to me that I might also mark it as pass-though but pass it through to nothing. Does this make sense? Will this achieve my aim? -- Chris

I've much to learn about dockers, @saarg, lovely things that they are, so thanks for that. Is there any particular objection to my using a custom network as described? It seems to be the logical and recommended approach. -- Chris