NAS

Moderators
  • Posts

    5040
  • Joined

  • Last visited

Converted

  • Gender
    Undisclosed

Recent Profile Visitors

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

NAS's Achievements

Experienced

Experienced (11/14)

64

Reputation

  1. The plugin has been updated. We all say thank you.
  2. We have slipped 9 versions out of date ` v2.17.3` released Apr versus `v2.21.0` released Aug. Too many changes to list https://github.com/docker/compose/releases Can I suggest with such a fast paced cadence upstream we look at a quarterly catchup backstop to avoid such sizable version drift. Excellent project. Invaluable.
  3. Right but it should be on users with problems to work around or disable modules and not for everyone else to hunt out and install addons for mainstream hardware. To be clear I am not critiquing you work, it is excellent, but this is not a rare component and has been on countless boards now for >10 years. It is a slippery slope.
  4. Whilst it is excellent that @ich777 created this package, drivers should be in the core OS and addon should be for edge cases only. Who is tracking feature requests these days @limetech this needs added to core.
  5. Thank you for the update to `Docker Compose version v2.17.3`. The fix for pull screen glitches is a welcome fix.
  6. Could we trigger an update on a semi regular basis? I do not know what your build pipeline is but I would like to avoid getting into a situation where we are essentially nagging you as a trigger. Even once a month or perhaps on each minor release could be automated.? Ultimately the end goal should be to make your life easier helping where we can; forking, splitting effort or taking away from your work should never be our goal.
  7. Can I ask about release cadence. Compose is now 13 versions out of date, is there any way we can assist in increasing this cadence? Does the addon need work every time the compose dependency changes? If so can we split this into two addons, one for compose itself and one for manager? Could we request compose be shipped with unRAID itself, would that help? Trying to understand where the bottleneck is as we just passed the 200 days mark since the shipped version of compose was released and that is too long. This post is not a criticism at all, just a realistic shout out to see if we can find a way to make this burden easier for you.
  8. Could I request an option to bypass this feature completely please. This would be a real quality of life improvement for compose users.
  9. This is a very long thread but I can only find issue reports and not a fix. How do I disable the image update warning entirely? I find myself starting to ignore Fix Common Problems because 99/100 it is docker noise and that cant be a good thing when that one time is important.
  10. Very much this. Is this an accepted feature request?
  11. I can confirm that spinning down a drive before you unpower it reduces or even removes completely the unpleasant noise. This is expected behavior since these noises are caused by the very action of un-powering an actively moving drive. This is not USB specific it is also true of hotplug albeit harder to hear because they are typically within a chassis. I apologize if this was not clear. I started this discussion from a position of already knowing that reducing the power state has this impact. What was not clear is how far "down" we could take them and the best methodology to do this within unRAID.
  12. Sorry for slow reply, I gave up trying to make my comments and quotes look pretty. I agree on `udisksctl`. We should not consider adding this as it is unnecessary. I only mentioned it as it had a documented caveat that seemed relevant to any similar approach. `If I implement a 'safely_remove' feature it will not be generic in the sense that it will not be done on every unmount. The user will have to add a 'safely_remove' command, and only USB devices will be operated on. You can appreciate doing a safe removal on a built in hard disk by accident. A reboot would be required to restore it.` Can we consider making this a button (or buttons) operation. I had imagined this never being event driven but rather would require a human button action in an identical manner to umount each and every time. This feels safer to me, allowing users not to press it of they choose (or even need) to do so if there are any edge cases out there. It would also let us add some safety where the button is only available within the correct context i.e. drive is not mounted. The term `safe removal` might be too harsh if we go this route since it implies not pressing would be `unsafe` which we have no proof is actually true. We can discuss terminology if this is agreed. `You can appreciate doing a safe removal on a built in hard disk by accident. A reboot would be required to restore it.` I agree that this would be a terrible situation but I expect that since we know `echo 1 > /sys/class/scsi_device/<scsi bus>/device/rescan` can reactivate a device we could create an action to undo this mistake. e.g. https://www.systutorials.com/docs/linux/man/8-rescan-scsi-bus.sh. I say this for two reasons. Whilst I agree with your conclusion about maintaining flash /boot writes is bad I suspect `I'm not sure a re-attach is practical for UD.` could also be covered by this generic scan/undo action without having to maintain a state or action memory. More importantly I would like to made sure hotplug disks are not excluded from this as there is no real need to limit it to USB as long as we can exclude arrays disks and have a scan/undo option. Should we create a new thread on this whole concept and discussions to attract more attention and make it easier to refer back to and google later?
  13. This is good feedback and even better practical advice. Obviously it is expected behavior needing to physically re-plug a device that has been fully removed although I admit is it not intuitive behavior. It does in my opinion reinforce the concept that a `warm and fuzzy` state exists below umount where the OS has released even more control of the device for safer removal. We are in a strong position to cater for this unintuitiveness since we will know that the disk is still there and which bus it was on so in theory at least we can have a reattach button. One unconfirmed edge case from udisksctl manpage Note that as some physical devices contain multiple drives (for example 4-in-1 flash card reader USB devices) powering off one drive may affect other drives. I am unsure if this impacts the more specific block action, testing will tell. I found linked via a previous suggestion this discussion discussing this approach on the Debian forums which is quite insightful.
  14. I think if nothing else happens that one single enhancement would add a lot of value.
  15. As I understand it the spindown command above requires every device be given an alias. I have no doubt this works since spin state is easy to change I just question how practical it is to require that the user define an alias first and for every device. For info this is not one specific drive, this is any spinning drive. It is easy to replicate, simply listen to the difference in sounds the drive makes between a spun down drive becoming unpowered and one that was just umounted and is still spinning. I also understand that spinning down a drive is not the same as a power off command we are just mixing the terms because we are ultimately just taking about the same end goal, safe removal. So to focus this a bit. Currently the procedure for removing a drive is umount power off I suggest there are more steps available to us: umount spin down Other options to explore such as eject/unbind the usb-storage driver/suspend the USB device Offlining the device e.g. echo 'offline' > /sys/block/XXX/device/state , Detaching the device e.g. echo '1' > /sys/block/XXX/device/delete power off If we feel that these are too complex or risky we should at the very least offer a generic "safely remove option" that just spins down the drive without any requiring aliases etc. It is not really a "safe removal" when compared to similar features in Ubuntu etc but its far better than just removing power from a potentially spinning drive TBH I think we can do much more here if we put our minds to it.