StatMatt

Members
  • Posts

    28
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

StatMatt's Achievements

Noob

Noob (1/14)

2

Reputation

  1. Absolutely 100% agree. I've had problems with drive replacements as well and the current process/steps seem VERY fragile. It needs a wizard.
  2. These two tabs should be one. The distinction of what is a "Tool" and what is a "Setting" makes no sense to me. When I'm looking to do something, I usually have to go to both of these menus before I find what I'm looking for since they're both kind of cluttered and not clearly organized. Why are User Utilities under Settings instead of Tools? Why is Update OS under Tools? If there is a logic to any of it, I've not been able to figure it out. The two menus should be combined and re-organized in a way that makes more sense to regular users.
  3. I have no doubt that what you're saying makes perfect sense to you as someone who does this everyday, but it makes almost no sense to me. I mean, I can understand the words you're using and what they mean, but I'm trying to figure out how a regular user would have any idea that the status for what looks like a physical disk is the actually the status for an emulated drive (assuming they even know there is such a thing as an emulated drive). Is there some obvious indicator that I overlooked? Even if I did know that, how would I have known there was anything I was supposed to do about it other than what I did? I had an old drive suddenly show up as "unmountable", so I replaced it. I'm not trying to be confrontational. I'm just offering feedback that I think could improve UnRAID as a product. Right now it seems like there are a number of things that are built in ways that apparently make sense to the devs (or ?) but don't make sense to users like me.
  4. Thanks for this tip. I did with the -v option. It generated a TON of output of things that looked alarming, but there wasn't any clear way to copy that log to a file from the GUI so I don't remember what it said. Went back to Main, stopped the array (because it had been in maintenance mode), restarted it, and everything seems okay.(?) Sorry, but I don't remember if it said that or not. If it did, I wouldn't have thought that weird because it was a brand new drive. Seems like it SHOULD be unmountable! The instructions (https://docs.unraid.net/legacy/FAQ/replacing-a-data-drive/) didn't say anything about formatting the drive or making it mountable or whatever - I just assumed that would get handled though the rebuild process. Just a comment: I've been using UnRAID for about a year and a half now, and this is the second time I've had a problem replacing an array drive. For most of users, I suspect replacing a drive is not an everyday occurrence. It would be super helpful if there were a "wizard" or something to walk us through the steps, because the documentation isn't great (doesn't it seem like something is missing between step 8 and 9? And to itimpi's comment how would I know that the if the drive is showing unmountable I'm supposed to do something else first?) and it seems like there are several "gotchas" that make the process fragile. Granted it seems like it's been fixed now, but I have NO idea what I did wrong, nor will I remember the details the next time an issue comes up. Thanks.
  5. I had an array data drive that dropped out of the array for some reason. It's an older 8tb SMR drive and I didn't completely trust it, so I decided to replace it with a new 14tb non-SMR drive. I followed the steps listed here: https://forums.unraid.net/forum/55-general-support/, although I'm not completely sure I remember any checkbox. Anyway, the machine chugged away for 24+ hours updating parity, but now the new drive is showing as "Unmountable: Unsupported or no filesystem". It's giving me a checkbox to format the drive, but it doesn't seem like I would want to format the drive after the parity has been rebuilt, right? Did I screw something up? unsmedley-diagnostics-20231027-1902.zip
  6. Sorry, one more follow-up question. I've successfully used the Unassigned Devices plugin to mount the old 6TB drive via a USB-to-SATA adapter. Now that I've got it mounted, I was thinking I would set up a user script utilizing rsync to move the files back onto the array. It's usually my practice to write to a share (mnt/user/*sharename*) and I have always tried to avoid directly writing to a drive in the array (mnt/*disk#*). For this scenario, would you recommend that I just copy everything to the replacement drive directly (i.e. /mnt/*disk#*), or should I copy to the share (for a few folders that would write to the cache pool, which has ample capacity for the contents of those folders) and let Mover sort everything out? Or am I completely off-base thinking about using rsync for this task? Any other suggestions? Thanks!
  7. Two thoughts: regarding the warning message maybe adding an example ("e.g. replacing a drive in the array"), and also maybe something like "(if your array currently has an emulated disk due to disk failure or routine replacement, formatting may result in loss of all data on the emulated disk")? Going a bit further, can you somehow have an additional check in the formatting process so if the array has an emulated disk that it gives either another stronger warning or maybe even prevents disk formatting (unless in enabled by checkbox somewhere deep in the settings that casual users wouldn't normally use)? Seems to me like it would be an edge-case where someone would need to format a disk in an array with an emulated disk, so locking out that functionality (with a work-around for those who really know what they're doing) may be best. I also agree that the documentation should clearly state that the filesystem cannot change during array disk replacement. Thanks for the opportunity to provide input.
  8. By the way, thanks for posting that warning. That was a couple of days ago and I didn't remember specifically what it said. Re-reading it now really helps me realize that I wasn't just being careless - I actually did read that message and honestly thought it wasn't relevant to my situation.
  9. In reply to JorgeB's post of the warning message: that warning says it'll lead to loss of all data on the drive being formatted. That is where I feel it might be confusing, because I know from past experience that if I'm adding a new drive into the array that any of the data it might have had on it would be lost. It wasn't at all clear to me that the drive being formatted was (apparently?) the EMULATED drive. I thought the warning was about the new drive, which was blank and I wasn't expecting or even wanting any files on it to somehow become part of the array. So this warning didn't seem applicable to me in my scenario.
  10. Obviously this is frustrating to me and not my intended outcome, to now have to mess around for several more days figuring out how to get my data back and off the old drive. I think the documentation and warnings could have been more clear about the fact that you can not change filesystem during a rebuild. It wasn't clear to me until you said it just now that the format was of the EMULATED disk (I don't even understand what that means, tbh) - it seemed to me like it was talking about formatting the new disk (which made sense to me - whenever I've added a new disk to the array one of the first things that needs to happen is for it to be formatted). If I can make this mistake, others can too which is why I'm suggesting updating the documentation and warnings. Data recovery question: Does it matter *how* I connect my old drive using unassigned devices? I have a USB3 drive bay that I could use - apart from some likely transfer speed disadvantages is there any reason I couldn't use USB3 instead of SATA? There aren't any more 3.5" bays in the server case so I don't have an easy way to put that disk back in.
  11. I somewhat remember a popup, but I thought that was a normal part of the process. This was my first time replacing a drive in the array so I didn't realize the message was abnormal. I thought it was just warning me that any existing data on the new drive would be wiped. I don't recall seeing any warnings about "format is never part of a rebuild". Why would it then spend nearly 2 days doing all of the reads from the other pool drives and writes to the new drive telling me that it was updating parity? Shouldn't it have been doing mostly writes TO the parity drive? Suggest updating the documentation and warnings to be more clear.
  12. I recently decided to upgrade one of my array drives from an older 6TB to a new 18TB drive. I followed the steps in the UNRAID documentation (https://docs.unraid.net/unraid-os/manual/storage-management/) and watched my server do a parity rebuild over the course of about 2 days. Now the parity rebuild says it's done. The old drive was about half full so it had about 3TB of files, but the new drive is now showing only 2.75MB (i.e. 0.00000275TB), so basically nothing. On the main tab if I browse the contents of the drive there are no files or folders showing AT ALL (it says: 0 objects: 0 directories, 0 files (0 B total)). It appears the parity rebuild didn't actually work. I was watching the main tab from time-to-time throughout the rebuild and it was showing tons of reads from the other seven array drives and writes to the new drive, so I'm really confused about where my data is. What do I do now? Not sure if it's relevant, but the old 6TB drive was formatted xfs, but I decided to try zfs on the new drive. I didn't think the underlying FS would matter for parity rebuild but maybe it does? I had most of my docker containers except Emby turned off during the rebuild, and this morning when I saw the parity rebuild seems to have failed. I also hadn't disabled mover, but I didn't think that was necessary since the documentation didn't mention anything about that. The old 6TB drive is sitting on the workbench waiting to be cleared for re-use for another purpose. I don't have an extra 3.5" bay in that server so it would be difficult to put it back but I could probably gin something up if needed. I also have another backup UNRAID server that I could put it in pretty easily (also a couple of Win10 boxes) if that would help, but I'm reluctant to do anything until I get some guidance. Diagnostics attached. bonzo-diagnostics-20230829-0904.zip
  13. I agree with this suggestion. The current UI design makes it difficult to understand how mover will work. It would be better if arrow always points the same direction as suggested by OP. Would make it much easier to understand what Mover will do and to confirm you have it set as intended.
  14. I hit the "Compute All" on the Shares tab literally 90 MINUTES AGO and it's still calculating. How could it possibly take that long? Could it cache the most recent result and display that with a timestamp and give the user the option to update that if it's not current enough? If I navigate away from the Shares tab, it'll have to start over. I'm trying to get the information to work on my file organization and the wait is extremely frustrating. Reminds me of another semi-related UI cache issue that I might submit as it's own feature request. Whenever I get a notification from Fix Common Problems that I have plugin that needs to be updated, I go to the Plugins tab and then have to wait (what feel like) 5 minutes while it's "checking for updates" for every plugin. I've never actually timed it, but it's bad enough that I leave the tab open and go work on something else. Somewhere the system is checking that information often enough that the results are known to the Fix Common Problems plugin, so why isn't a cached result displayed on the UI? There are a lot of things to like about UnRAID, but the UI can be maddeningly slow!
  15. That was super-weird. I rebooted my main unraid server, and once it re-started suddenly the little bulbs were green and I was able to mount the remote shares on my Win10 box, but at the same time my backup unraid server no longer showed as online so that remote share couldn't be mounted. I went in a pinged it, and once I did suddenly it also started working (after a couple of tries - I forgot UNIX is case sensitive). Something very strange seems to be going on with name resolution on my network - will have to try to get to the bottom of that. Thanks for your help.