Joseph
-
Posts
444 -
Joined
-
Last visited
-
Days Won
3
Content Type
Profiles
Forums
Downloads
Store
Gallery
Bug Reports
Documentation
Landing
Report Comments posted by Joseph
-
-
On 2/19/2021 at 8:18 PM, DaveDoesStuff said:
This was resolved by installing the Nvidia Driver plugin (and possibly limetechs underlying nvidia driver stuff).
Interesting... I had the same problem.. seems the culprit was the NVIDA driver plugin that I had installed awhile back. Deleted that and now it's back.... hope this helps someone else.
-
8 minutes ago, Squid said:
The first part is to be expected after the update. The second part is a known issue
gotcha... sorry for the unnecessary post then. I looked around and didn't see anything directly addressing the 2nd part. my bad for not doing enough dd.
Nevertheless, thanks for the clarification.
-
4 minutes ago, trurl said:
And of course, everyone would ignore it. Or complain about it.
True, if it's generic and wasn't specific to an actual change in the array.
-
7 minutes ago, jonathanm said:
I suppose the best way to handle your specific issue is a warning message when you start the array...
That's kinda what I was thinking. But like you said, developer time might be better spent on other more important issues.
-
22 minutes ago, trurl said:
Short of a parity check, how can Unraid know you haven't done anything to any of your array disks when it was shutdown? And even then, it won't know why parity is out-of-sync. How could it?
Perhaps it would know the file system is no longer the same as it once was and/or the power on hours from SMART have changed since it was last shut down? IDK
-
Quote
That's correct. A correcting parity check would have updated parity to reflect what was now on the disk instead of what was there before
So my first assumption was correct: starting unRAID at Step 3 would have killed the contents forever.
My concern for raising this as an issue is, unRAID would have known something was wrong if it was a different disk and alerted the user. But because it was the same drive, it thought all was well. Perhaps that's by design, but some kind of warning would have been nice. IDK.
QuoteYour scenario of pulling a data drive to temporarily use it for something else doesn't make sense.
LOL @jonathanm...TRUE! It doesn't make sense and I hope no one would ever try it -- especially on a production box. But since this was on a test box, had I have lost the contents, it would not have really mattered.
FWIW, I needed an extra 4TB of space on a mac and didn't have any drives laying around large enough to complete the project. (whatever data I had on that drive, has been restored since I ensured unRAID understood that drive was 'lost' and it rebuilt the contents from parity.)
My apologies to everyone if I've wasted time on a non-issue, but it seemed like a way to improve the product to "save the user from themselves" for those of us who suffer from 1D10T errors.
-
Ok, thank you. I was concerned based on the 'new contents' of the physical disk, it would have destroyed the virtual contents held by parity and the data that used to be on the disk would then be forever lost... which is why I thought it might need to be reported as a 'bug', annoyance, or whatever. It would still be nice if there was some way that unRAID could somehow recognize when a disk has drastically changed prior to startup to warn the user. But thank you again for looking into it.
-
Thanks Squid for the info. So, to make sure I understand... in my case, even though the drive was returned to unRAID but partitioned as OS X Journaled, had I started the array in step 3, unRAID would have continued to 'work' and once a parity check was done, it would have restored the partition of that drive back to XFS and rebuild the contents of that drive from parity?
-
+1 here for poor network performance (well actually, I have 2 with poor network performance; but I digress)
sorry for the noob questions, but consider the following:
#disable SMB1 for security reasons [global] min protocol = SMB2 #Are the 3 space before the above setting necessary? [global] #Set Case Sensitivity - can comments go after [global]? case sensitive = true default case = lower #can comments go on the same line? preserve case = true short preserve case = true #vfs_recycle_start #Recycle bin configuration [global] syslog only = No log level = 0 vfs:0 #vfs_recycle_end* Is the syntax/formatting correct? (Does placement of CRs matter, placing comment lines after [global], etc.?)
* Is it better to have just 1 [global] heading and put all global setting after it?
* How does unRAID know when global instructions end? there's not [/global] or something to indicate.
Thanks for any assistance that is offered!
Time Machine unbelievably slow
in Stable Releases
Posted · Edited by Joseph
I'm going to guess it was the last one you tried that 'fixed' it 🧐
btw, I've got the same issue too and I have to delete the entire sparsebundle and completely start over every time it gets borked (haven't tried running TM outside the array yet.) Frustrating to say the least!