NAS

Moderators
  • Posts

    5040
  • Joined

  • Last visited

Everything posted by NAS

  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.
  16. Can we come back to this. It is not obvious to me what the correct method to remove a drive as safely as possible. Can the current method be improved because you can clearly hear the drive head horribly clunking if you go directly from umount to power off? There are many threads discussing this one is the most simple. https://unix.stackexchange.com/questions/35508/eject-usb-drives-eject-command (It is labelled USB the content quickly becomes more generic than that)
  17. Addon works great. What are your plans for patching compose. I can see that the opening posts says version 2.1.1 however the plugin change logs says: 2022.05.14 Change default output style to terminal. Added theme support. Docker Compose v2.5.0 which matches what is included: # docker-compose -v Docker Compose version v2.5.0 but according to https://docs.docker.com/compose/release-notes/#250 this is three months and three releases out of date.
  18. Has any discussion happened on mechanic disk head parking on umount? When I press the interface button to umount and then physically power off the drive I can clearly hear the disk doing something that sounds a little awful. As an experiment, immediately after pressing the interface button, I issued the following command to the external USB disk: hdparm -y /dev/sdt and whilst I get an error: issuing standby command SG_IO: bad/missing sense data, sb[]: f0 00 01 00 50 40 00 0a 00 00 00 00 00 1d 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 it seems to work and powering off the disk sounds less harsh. This is proof of concept only, just enough to check the theory to open a post here for discussion.
  19. Thank you. Even after mounting countless hundreds of disk using UD I was not aware of those settings in the GUI at all. Perhaps that hints at either PEBCAK or an area where interface changes would help. As for image work, I cited that specific example as it was easy to do using the wiki itself but other examples include the more mundane tasks of backing up disks, thumb drives, RPI SD cards etc but I accept that these examples whilst not disk recovery are still intended more for the sysop than the average user. Thank you for the education and consideration.
  20. Nothing especially complicated I am just suggesting that disks should only be mounted RW if you actually need RW. Failing that an option that allows you chose RO. For example if you are loading data from a backup then RO would be a safer option especially in the scenario where you are needing to restore from backup in the first place. As for working with images this gives a practical example of a use case https://wiki.unraid.net/Manual/Troubleshooting#Using_ddrescue_to_recover_data_from_a_failing_disk
  21. Any thoughts on this? If image options are out of scope please consider the read only mount option. There is a lot to be said to mounting disks RO by default with an option to seamlessly remount RW if needed.
  22. Not a VM thing just a normal raw imaging action such as: `dd if=/dev/sdX of=/mnt/mybackup.img` or in reverse `dd if=mnt/mybackup.img of=/dev/sdX` There are many other options such as compressed images, partition images etc but all are just variations on the theme of disk image handling.
  23. Apologies if this is covered in the previous 252 pages but has consideration been given to adding the ability to mount and/or create disk/partition images (typically using dd in the background) Perhaps niche but genuinely useful especially if RO mode is an option.
  24. Suggestion for Update Assistant part of Fix Common Problems. Check all users for any instances of screen running.
  25. This clearly falls within the bounds of the release methodology. I appreciate the conflicting pressures and associated costs but its time, 332 days between security releases is pushing it a bit.