PeteAsking

Members
  • Posts

    514
  • Joined

  • Last visited

  • Days Won

    3

PeteAsking last won the day on May 31 2022

PeteAsking had the most liked content!

Recent Profile Visitors

2996 profile views

PeteAsking's Achievements

Enthusiast

Enthusiast (6/14)

102

Reputation

  1. 7.4.156 was released to official 14 hours ago. I have an upgrade to this version scheduled for 13/06/2023 (13 days time - will post an update 48h later) if anyone is wanting to wait along for the test at this time where I will check the forums for issues and then update if it seems all clear. Otherwise if you choose to update then you are on your own and just tell us what happened. Kind regards Pete
  2. It should be safe but some old devices could stop working if you have any in your environment. There have been many posts about various old devices in this thread and how they have issues. You should review that unless all your devices are on the newer side.
  3. UniFi Network Application 7.3.83 has received multiple patches over the last 3 months and should be considered the "best" latest version for anyone who does not require a legacy version such as 5.14.23-ls76 or 6.5.x for older hardware. So if you are on tag 7.2.95 you could upgrade to this 7.3.83 tag safely I imagine. Current situation: Legacy systems: 5.14.23-ls76 or 6.5.55 versions seem fine. (AKA "old old old stable" or "old old stable"). Wifi6/New Deployments: 7.2.95 or 7.3.83 tags are fine. (AKA "old stable" or "stable"). Do not use tag: "latest" unless you are an alpha tester who fixes their own problems. Posting this info because of the upcoming next release (7.4.x) AKA "alpha" Kind regards Pete
  4. I mean on the unraid server itself. Im wondering if you used like 85% of the ram by allocating it out or copying a large file to the server (ram is used in file copies then written to disk after) and the OOM killer ran and ended a service that should not have been ended.
  5. What amount of memory is typically in use at that time on your server? Was it high?
  6. @3x3q could the above have happened to you?
  7. What if the usb disk was disconnected during the time for any reason this happened so unraid could not write to the usb that there had been an array interruption? What happens then - ie all is perfect, usb becomes inaccessible (same thing that drops disk?), issue occurs then reboot?
  8. It is interesting that you say this because if you download the diagnostics of the reddit users post I posted earlier on the domains.cfg file it states: shareUseCache="yes" I imagine as opposed to "prefer" Unsure why.
  9. Not sure but another scenario I am thinking of as it happens sometimes after a power failure is that something has happened between the state of the machine when it was powered on and after it got rebooted due to a power failure. I am wondering if a common issue on the forum where a bad cable causes a disk to drop off TEMPORARILY could be something like this: 1) Unraid is functioning normally 2) A bad cable causes a disk to drop off the array temporarily (this could occur after the mover begins moving the file and is mid way through moving?). 3) A mover is invoked and it moves a file from a cache drive to the array that is now enumerated. The file is removed from the cache and the file is assumed to be on the array. 4) Unraid is rebooted due to some event (power failure, user intervention etc). 5) The disk comes back online as it was a temporary fault. Unraid starts the array? Unsure about this part. Possibly required manual intervention here? 6) The changes that were being enumerated on the parity disk are lost as now all disks are available so there there is no enumeration taking place. The file that was moved to the array no longer exists. Thoughts?
  10. I understand the intention of the mover, but as nothing is perfect it may be possible for an unimagined scenario to allow a file to move that should not have been possible. Ruling this scenario out without rigorous and detailed mathematical proof it cannot be possible ever seems strange to me.
  11. A reddit user here has had the same issue occur: It also happened after a power loss, so while filesystem corruption is possible it seems like something additional must be needed for the failure to occur. I also agree that its possible the mover has something to do with the scenario as it is directly manipulating files, possible during or around the time of power loss. In linux it is possible to delete a file in use as it does not actually remove the file, it just reduces the inode count by 1, and when the inode = 0 then the file is freed up from the filesystem. This can explain why user @3x3q was able to have a running VM with no file (but the space was not freed until the process holding the file was ended). If 3x3q had used the command "lsof | grep <name of missing file.qcow> most likely he would have been able to find the file and copy it to a new location using the "cp" command from /proc. Its possible this may have saved the VM if he had done this before turning off the VM. It would be interesting to see if the disks used by people with the issues are similar. Just adding this here as the number of reports is somewhat higher than random chance would suggest it should be. P
  12. Their logic is they said one time dont do this, people did it and found it worked, so they feel they have no obligation to help. Same for unsupported devices. They have said dont do it, dont upgrade. If you continue to do it and it causes some fault, then dont expect any help from them. in addition expect them to actively try break something...
  13. I think a lot of us have been surprised that updating the controller software can break devices or stop them working, and that you have to check your site before running an update to see if its compatible. Its actually quite tricky to know because some changes fly under the radar. On one hand the hardware is excellent and works reliably and well, and is cost effective. On the other had the software controlling it is very dangerous in a business setting to just blindly update. Its really a shame because unifi let themselves down and it reflects badly on their brand.
  14. Also dont forget ‘obsolete’ just means unifi one day decided they dont support them. It doesnt mean they are broken. Most times the hardware is still reliable and fast enough for daily use. Sent from my iPhone using Tapatalk Pro