falconexe

Welp, I just read something that I was not aware of, but it makes total sense: So, should I just stop the data rebuild if the rebuild is going to be corrupted anyway? Or am I fine BECAUSE I HAVE DUAL PARITY? I could throw back in my original 8TB disk and try to get disk1 resolved? I am now REALLY thinking that I should not do anything until someone with experience chimes in. If the data rebuild is going to be corrupted on my new 18TB disk because disk1 had 2048 read errors, what is the best protocol to NOT LOSE DATA at this point? I always thought if you had dual parity, even if a disk failed during a rebuild, everything would remain intact so long as you didn't lose a 3rd. Currently, everything is still accessible. I have the original disk I am expanding from, and I have spares to replace disk1 if needed. Thanks again!

Hey everyone. I've been running my 30 drive server for years without any issues. Today, I decided to swap an 8TB drive for a new 18TB drive. New drive was previously successfully pre-cleared. So, I went ahead and swapped it out and started a data rebuild. I've upgraded over a dozen drives in the last year the same way, without ever having an issue. Today my luck ran out and Disk1 (1.5 year old Seagate 14TB with XFS) threw 2048 read errors and went offline (red X) about 30 mins into the rebuild. It is now showing up in the Unassigned devices area. I checked the file system and it shows corruption. Short SMART was perfect. Long SMART is not able to be run currently (greyed out). All attributes look normal. SO, just because it has been a VERY LONG time since I've dealt with this, and because I have seen a lot of people lose data and make the situation worse by panicking and making mistakes, I just wanted to run my plan of action by everyone. Open to any advice, and any help is appreciated to keep me on track for a successful outcome. 1. The data rebuild is continuing and has about 50+ hours left. I will not stop it as disk1 is emulated and the data is accessible. Since i have dual parity, I am only going to be in a world of hurt if a 3rd disk craps out. Fingers crossed... 2. Once the data rebuild is successful for the new disk I just swapped, I can either try to repair disk 1, or just swap it for another new 18TB disk. I have plenty of spares on standby. Questions on #2. If I did want to attempt a XFS file system repair, and if that was successful, how do I get it back into the array? I was planning on a full shutdown, re-seating disk1, then attempting the repair via the "RUN WITH CORRECT FLAG" button. I've never ran this before, so have no idea what to expect. If it is successful, will the disk just pop back into the array like normal, or after a reboot? I could also just throw this disk into my backup server, run a new pre-clear, extended test, and see if it is stable. If it is, then at least it is serving some purpose in expanding my backup server's space, and I don't have to worry about it blowing up again in my production server. For now, I am not going to touch anything until the data rebuild is finished. I'll refrain from posting diags, and just looking for overall advice. Thanks and Happy Thanksgiving!

While I was researching how to currently install Varken, I noticed that it only supports InfluxDB 1.8. From the Varken GitHub: https://github.com/Boerderij/Varken So, if we were to move the UUD to Influx 3.X using SQL, it would require someone to pick up the mantel on Varken, and branch it. If anyone is serious about it, and willing to continue that project, I'm willing to try and get the UUD to Influx 3.X in tandem, once they release it and we can get our hands on it. Once Varken's repository is gone gone, the main part of the UUD that I use (Plex) would need something else to get the Tautulli data into InfluxDB. I'm open to suggestions. We don't necessarily need Varken, we just need the code equivalent that moves the data. Perhaps a direct API call from Tautulli to InfluxDB? Let me know your thoughts (anyone). @Jufy111 @viktortras

Varken is no longer being developed, but I still see it in Community Applications, and it doesn't appear to be officially deprecated. Do you see this? This is the way it is installed.

I found this using a web search. Please open a topic on InfuxDB’s forum. I have never seen this before, and it sounds like you have reached the upper limit regarding cardinality. I have data going back 5 years. My InfluxDB database is 100GB+ with millions of records. Something seems off. Let us know when you get it figured out, and how, so others in the future have the help they need too. https://community.influxdata.com/t/max-series-per-database-limit-exceeded-1000000-error-question/12273

I really appreciate this info. As a result, I have added you as a contributor on page #1. Once I get my server updated to 6.12.X, I'll give this a whirl. I may pick your brain on some stuff if you are up for it in the future. Thanks!

Na, don't feel obligated. I appreciate the info you have already provided and that is a contribution. A lot of people have helped over the years with providing me leads for the UUD. If you want to help with InfluxDB 3.0 stuff, I'm all for it, but no pressure. Thanks.

Thanks! Yeah man, no worries. It was long overdue. Let me know if you get the Jellyfin stuff figured out. I run Plex, but I can maybe add some similar stuff if it makes sense on that side of the house. I also wonder if there is an equivalent data ingester for Emby?

This is fantastic news, as I am a professional SQL developer. So yeah, I'll wait until InfluxDB Edge/Community comes out and roll with that. That should make it a lot easier to query the dataset and will open it up to a lot more of a mainstream/professional user base. Maybe we can work together (if time permits) to get something figured out to support this in the UUD. I suspect we'll need to wait until a new docker becomes available for InfluxDB 3.0. I am not a docker dev, but I'm sure someone will get on it eventually. I added you as an official contributor on post #1!

Pretty much just take a simple query from 1.8 and show me the translation to 2.X. If I can see how the query code syntax changed, I'll get it figured out. I haven't even looked into this officially, but I have heard all about it. Massive undertaking considering there are 100+ panels (hundreds? I've never counted LOL) in the UUD. It will all come down to time, and I'm an extremely busy guy for sure with work and family obligations. I appreciate the help and will add you as a contributor to the project once this gets rolling.

There is nothing to my knowledge in the 6 required dockers (Grafana/Telegraf/InfuxDB/Plex/Varken/Tautulli) that wouldn't work in the latest release of UNRAID. This is literally a JSON file and totally independent of UNRAID itself. It just displays the info from UNRAID. Not sure what you mean by "Manual Install Download Page" and "latest in a branch now". The UUD IS NOT ON GITHUB. Anything on GitHub is NOT OFFICIAL and is NOT SUPPORTED. This is the only official place to get the UUD. A lot of people have taken my JSON and bundled it with dockers, integrated it with a bunch of other software, and straight up just took it and called it their own. Though flattering, I cannot control and/or support these "unofficial branches". Finally, please elaborate and link the issue with remote mounts. I have not heard of this until now. What remote mounts would you be using the UUD with? To my knowledge, there is nothing in the UUD that uses remote mounts. If that is something you are doing, it is a custom you implemented. Honestly, I've been holding out on upgrading my UNRAID OS since there are no new features that interest me personally, and 6.11.4 has been rock solid. However, security is important, so I'll tell you what. I'll go ahead and update my server to the latest release this evening. If it breaks the UUD (doubtful), I'll resolve any issues and report back. There are NO SECURITY ISSUES in the UUD as it is ONLY a JSON Dashboard for GRAFANA which is completely independent of the UNRAID OS. Stay tuned... @SpencerJ

I just updated the release post with a bunch of info, direct download link (linked from post 1 of this thread), and a bunch of tutorials. READ POST #1 to get started.

Yes, still running on InfluxDB 1.8. If/when I decide to move to InfluxDB 2.0+, I'll rebrand the UUD as "UUD 2.1". I may do this and reintegrate the new version of the UNRAID API-RE at that point. I will likely also update Grafana to version 9+ and take my unRAID 0S to the current release as well. If I take on this project, it will be out of necessity. Great question BTW. I may pick your brain at that point if you are open to assist.

Thanks for this info. I was not aware of this. I'll take a look into it and may integrate it back in. Does anyone know if that memory leak was patched/resolved with this branch?

@SpencerJ Please add UUD 1.7's release to the official UNRAID Blog/Emails. Thanks!