RobJ

Dan, I have to agree with johnnie.black. For whatever reason, users just do it. They format with UD and expect to add it to the array, and are shocked when it doesn't work. I imagine some do it from ignorance, but even so, it should still work. Others do it intentionally, perhaps as part of an initial data migration strategy - preclear and format a set of drives, take them to another system to fill with data, then bring them back to start an array. Others don't intend to do it initially, but may later change their mind and decide to add the drive to the array, for better fault tolerance perhaps. After all, they think, it's already formatted with XFS, so it should be easy to add. I don't know the reasoning for sector 2048, so I may be wrong, but as far as i know, sector 64 is just as optimal as any other optimal starting sector. I think it would be good for unRAID to be more flexible with what it accepts and can work with, but for now, it's the gorilla, and I think it would be wise to conform to what it wants.

just like all the other ones, via a LSI 9300-8i Host bus. Although the new drives are with two new Host bus adapters that I ordered. Perhaps there is a driver issue there? Please see Need help? Read me first!, and attach the diagnostics zip.

I can't help with the compiling, but if you contact Tom at [email protected] and specify what you need and the code you have found, he will probably add support to an upcoming release.

I wasn't sure at first why you thought that, but then figured out you must think that unRAID always knows what's on each disk, even after being removed from the array. When you add/assign a disk to the array, unRAID does not know what is on the disk, whether it's empty or has data, and if there's data what file system it is using. And worse, when this was written, the file system was not cleared for an unassigned drive, so that if you unassigned a Reiser drive at Disk 10, then assigned an XFS disk there, it would still be marked for ReiserFS, until you manually changed it. I suspect recent updates have changed that, but it would be marked as Auto, meaning it's supposed to try and figure out the file system on next use. In the past, Auto was not reliable, and sometimes failed, leaving the drive marked as Unmountable, which results in a prompt to format the drive, which obviously can be disastrous. The whole point of that instruction is to make sure that the file system for the drive is correct after the swap, because it will NOT be until you set it correctly. I'll try to see if there's a better way to word it. To illustrate what happens - Before swap: Drive R Disk 10 ReiserFS Drive X Disk 11 XFS After swap of assignments: Drive R Disk 11 XFS or Auto Drive X Disk 10 ReiserFS or Auto After FS correction: Drive R Disk 11 ReiserFS Drive X Disk 10 XFS

Shouldn't it be? It seems to me that it would be better for consistency if all formatting functions worked the same way, for interchangeability?

I can't point to the studies that corroborate it, but it's long been my understanding that hours spinning is not as hard on the drive as number of times it has to spin up and down. If the drive needs to spin up and down a few times, then it's my understanding that the drive will last longer staying spun up. Minimizing drive hours is not as important as minimizing spin changes. A spinning drive does use more power, and generate a little more heat, but will probably last longer with fewer spin ups and spin downs.

Try unRAIDFindDuplicates.sh, I think it should help. Otherwise, I would use a double pane file manager, like MC or Krusader or Dolphin, to compare folders and delete the duplicated folders and files.

Interesting to see an almost brand new system getting started. I suspect you had previously started, and formatted the 2 data drives with XFS, then re-prepared the boot drive cleanly, and started again. It started with apparently nothing configured, then you began configuring various network and identity items, installed a few basic plugins, then assigned drives, tried an array startup, stopped it, made a few more changes, and started again. But only a minute after installing 4 Dynamix system plugins (Stats, Temp, Info, and Buttons), the php segfault occurred, and shortly after that a number of diverse things went wrong. I suspect the segfault was the first indicator of an unstable system. But I don't see any obvious dependency issues, and you have tested your RAM (the usual suspects for segfaults). Because it happens so close to the installation of those 4 plugins, I'd start there, eliminate several of them, and try starting with and without different combinations of the 4, see if you can determine if one of the 4 is malfunctioning within your system. It seems unlikely, but we need to start by eliminating them as suspects. @bonienl may want to monitor this, in case there's an issue with them. There are a few odd workarounds in your syslog, so try checking for a newer BIOS version. It probably won't help, but it's one more suspect we can easily eliminate, if there's a BIOS update.

I have no personal experience, don't use a cache drive, but what you suggest sounds correct. Toggling Turbo Write on should speed up Cache:Yes moves (but not Cache:Prefer moves). However, some perspective would be good. The Mover is designed to do these moves at a time when the system has the least usage, generally an early morning moment when you know everyone of its users will be sleeping. So do you really care how fast it is then? You're sleeping! What you might care more about is that a number of additional drives had to be spun up too, that normally would have been sleeping too.

Great to see you back! I suspect once you hop back on the bike, it will all come back pretty quickly. But take your time, as I'm sure you have learned, some things are more important than us! I also suspect you will have lots of willing helpers, ready to test anything you want tested. It's always good to make anything that's of value to the community readily accessible and editable by the community. But we will still need and want you in charge of it!

@gfjardim, this (no need for screen any more) sounds like a good candidate for a Q & A, in your first post.

And since we're on the subject of feature requests ... First, thanks for adding TRAY_NUM to the historical lists, and for the Areca support! This one is an expansion of the historical slot number, and isn't strictly necessary, now that you've added the slot number. But the nice thing about this plugin is that it establishes the relationships between the virtual drives and the physical drives. In keeping with that, it would be nice to still see the unassigned or disabled drive still in its slot, where it still physically is, even if the kernel can't see it. Perhaps grayed out? It wouldn't have drive numbers or device symbols, but would still have its physical identification. Then we would need a blanking action for slots, that corresponded to the physical removing of a drive. A second request, this one is a small issue. Your plugin is one of the few sources of confusion about what is spinning and what is not on the Main page. When SMART requests are done, they spin drives up (unless the drive is a WD), but the SMART request does not notify unRAID (emhttp?) that the drive is spinning. So temps appear, but the drive cannot be spun down, because the system still thinks it is spun down. You have to manually spin them up (even though they are actually already spinning), before you can spin them down. Not sure of your best course, but perhaps issue an unRAID call to spin all drives up? That will keep spin states correct.

As Squid said, that's not an error. For many of us, that's desirable behavior. Somewhere, back a ways, there's a discussion about this.

Most likely, it just needs to write the new list to its config. Just make a change and save. Or change something, save, then change it back and save. You need the corrected list saved to the config file, removing the old entries. I would also turn off "Scan user shares", because it's usually redundant. Unless you have clearly found something that only gets cached with that setting on. Otherwise it's wasting memory and time.

As most know, there was an 'accident' and the Docker FAQ was lost. It has now been restored. Because there was considerable handwork involved, there is a chance for errors, bad links, etc. Please let us know in this thread if you find any problems.

I've updated that wiki page partially, but it needs more work. Thanks for reporting that.

Thank you! I'm just using this now, just printed out both the Layout and Data pages, before moving everything to a bigger case, different layout.

I just ran into this a few days ago. A feature request, add the the last used slot number to the historical listing for a drive. Some of us don't always remember to visit Server Layout first before unassigning a drive.

Because you turned on Turbo Write, ALL of the other disks have to be read in order to determine what to write to the parity disk. For this operation, Turbo Write is faster that the alternative, but clearly it's not helping you. Because Turbo Write depends on ALL of the array drives, and it cannot move faster than the slowest drive, it's my suspicion you have a bad drive somewhere, that's dragging down the rest. Your syslog may be full of drive errors, post your diagnostics. That would be correct for the Read/Modify/Write method, but you changed it to Turbo Write (which would normally be faster here). While it's possible to overwrite the space of each file with zeroes, that's not enough, you still have to zero out ALL of the deleted files, the remnants of past files, and the past versions of files, AND ALL of the sectors of the file system itself. We don't know where they are. For modern file systems, they can be scattered over the entire drive surface.

were you able to resolve this? I am getting the same error when trying to install the docker. bdee1, I tried to point bfeist to the Docker FAQ, where the answer is, down in the Troubleshooting section. This has been a common issue, one I've highlighted in the Docker FAQ index.

Just an idea for Tom - create a second build that includes ZFS support, and charge a premium for it, to cover the ZFS licensing, development, and extra support costs. So in the future you might release both 6.4.0 and 6.4.0Z. Because of your point 4, you may choose to release fewer Z releases than main releases.

The function needs to remain, but it could do with a renaming. I purposely have shares that I keep data manually switched between fast SSD cache and slower array disks, based on usage. I need that share to write new files to the cache drive, since fresh files are typically referenced frequently for a while. As the data ages, I manually move it to the array folders so it's still available, but not high priority. An automatic version of what I manually do has been discussed in the past. Hadn't considered that. An excellent adaptation of a builtin feature. There has always been some confusion with the Use cache feature, and it perhaps got even more confusing when Prefer was implemented. I like the current functionality with the 4 choices, but even if you spelled out exactly what the 4 choices do in the webUI I think some users would still be confused unless you went to a lot more trouble to discuss possible scenarios for each as you have done here for cache-only. I heard trurl's hint - and I've added scenarios to the FAQ entry. Feel free to edit, expand, or offer improvements.

Perhaps a simple user script run by cron that periodically moves the folders into the Recycle Bin folders?

Can you explain the Cache drive option types, and what is the difference between them? Here is a table illustrating the differences: Table of Cache drive usage options and their behaviors C=Cache drive D=Data drive(s) Cache:No Cache:Yes Cache:Only Cache:Prefer Data should be on: D C+D C C+D New files first to: D C C C Files overflow to: - D - D Mover moves: No C to D No D to C Orphaned files: C - D - Notes: - Orphaned files are those files located where they don't belong (e.g. files on D with Cache:Only), they won't be moved by the Mover - Files on both C and D are still visible in shares, for all options - Shares are all root folders on all array data and Cache drives - New files overflow to the secondary destination when there is not enough space on the preferred destination - Cache:Prefer is the newest option. In general, it is now preferred over Cache:Only because it behaves the same but adds overflow protection. If you fill up the Cache drive, copying to that share will continue to a data drive, and not error out, as it would if marked Cache:Only. And if the Cache drive drops out, you will still be able to continue, using a data drive for the same share. Once the Cache drive is restored, then the Mover will move the share back to the Cache drive. Some typical usage scenarios Cache:Yes - data is written to the Cache drive, then Mover moves it to the data drives - This is the typical Cache drive usage for large shares, to speed up writes to the array. The data will mainly be stored on the parity protected array, but writes will be at full speed to the Cache drive, then later moved at idle times to the array. Cache:No - keeps all data on the data drives - This is similar to Cache:Yes, but doesn't use the Cache drive, which is fine if you don't need the speed boost when writing files to the shares. - An alternative usage is to keep most of the data on the array drives, but manually place selected data on a fast Cache drive, in the same share folders, for faster access to that data. It is still visible in the share but won't be moved to the data drives. For example, commonly accessed metadata might be placed there. This may help keep the data drives from spinning up. (This is similar to the alternative usage of Cache:Only) Cache:Only - keeps all data on the Cache drive or pool - This is typically used for smaller shares or shares you want faster access to. - An alternative usage is to write and keep new data on the Cache drive, but manually move rarely accessed older files to the same share folders on the array data drives. Both sets of files are visible in the share. This may help minimize data drive spin up. See this post. (This is similar to the alternative usage of Cache:No) Cache:Prefer - keeps data mainly on the Cache drive or pool, but allows overflow to the array - This is similar to Cache:Only, typically used for smaller shares or shares you want faster access to. But it has additional advantages over Cache:Only - data that won't fit on the Cache drive can overflow to the array drives. Also, if the Cache drive fails, the same share folders on the data drives will still continue working. It's also useful if you don't yet have a Cache drive, but are planning to get one. Once it is installed, the Mover will automatically (on its schedule) move all it can to the Cache drive. And if you need to do maintenance on the Cache drive or pool, you can move all the files to the array, and they will be moved back once you are done 'maintaining'.

I put together a little table that may be helpful. Table of Cache drive options and behaviors C=Cache drive D=Data drive(s) Cache:No Cache:Yes Cache:Only Cache:Prefer Data should be on: D C+D C C+D New files first to: D C C C Files overflow to: - D - D Mover moves: No C to D No D to C Orphaned files: C - D - Notes: - Orphaned files are those files located where they don't belong (e.g. files on D with Cache: Only), and won't be moved by the Mover - Files on both C and D are still visible in shares, for all options - Shares are all root folders on all array data and Cache drives - New files overflow to the secondary destination when there is not enough space on the preferred destination.