Hi
I use usbbackup plugin to synchronize my backups to an external Tandberg RDX drive which works fine. After the backup I would like to eject the cartridge (eject /dev/sdxx). Is there a way to execute the eject command automatically right after rsync has finished?
THX a lot!!!!
Sorry. that's not possible.
Sure, it is a shell script that can be modified, but when OMV recognises the need to rebuild the script because of configuration changes, then your changes are overwritten.
I don't see the need of a feature request because the name of the plugin implies that it is for USB usage. Unmouning the filesystem is enough for this scenario.
Maybe there is a way to implement that a generic way, otherwise i had to reject this feature request. I don't want to implement a checkbox or something else to support that. If the device is known as removable to the Linux kernel, then it is possible to use that generic feature to eject the device like it is possible to CD-ROM devices.
Please execute the following commands to evaluate if the device supports this:
# ls -alh /sys/block/<DEVICENAME>
# cat /sys/block/<DEVICENAME>/removableOk, did some research and it seems every USB device can be unmounted with eject. You never stop learning. With this it is simple to support your request.
Great! Thx a lot! Thx! Thx again! I'll test and report!
Is there a way to execute the eject command automatically right after rsync has finished?
What is the requirement behind it? What is the problem of pressing the eject button?
When the cartridge is ejected when the backup job is done it is no longer possible to store another job on the same cartridge. Or is the RXD drive able to feed-in the tape automatically when a mount command is executed?
I admit that this kind of drives are probably rarely used. Nevertheless for me, there might also be good reasons not to eject the cartridge in general.
What is the requirement behind it? What is the problem of pressing the eject button?
When the cartridge is ejected when the backup job is done it is no longer possible to store another job on the same cartridge. Or is the RXD drive able to feed-in the tape automatically when a mount command is executed?
I admit that this kind of drives are probably rarely used. Nevertheless for me, there might also be good reasons not to eject the cartridge in general.
Good points, but the tape is only ejected when all jobs that are using this device are finished. This also happens only if you plug the USB device, but not when you run the job via UI.
The only problem is that if you reboot the system with a plugged device the rsync job is triggered automatically by UDEV and ejects the device after the sync (incl. removing the device node), which makes it impossible to run the jobs from the UI again. Another problem is when you want to add additional jobs when there are existing jobs. In that case you plug the device, the jobs are running and on success the device node is removed. Because of that the UI will never be able to let the user choose the USB device in the job creation dialog because the device node does not exist anymore.
Hmmmm, seems there are some arguments that prevent this PR.
I think we have to close the PR if there is no other way to eject the tape without removing the device node. Maybe sysfs can help here, e.g. echo '???' > /sys/block/sdb/device/<???>. Any help is appreciated.
Good points, but the tape is only ejected when all jobs that are using this device are finished.
If it is implemented in this way, then it is no longer a problem.
Another problem is when you want to add additional jobs when there are existing jobs. In that case you plug the device, the jobs are running and on success the device node is removed. Because of that the UI will never be able to let the user choose the USB device in the job creation dialog because the device node does not exist anymore.
That could be prevented by disabling all backup jobs temporarly for this device, before connecting it. Then plug the device in, create the new job, disconnect it and enabling the already existing jobs again at the end.
But this is more or less a workaround and could be a lot of work depending on the amount of existing backup jobs.
I admit that this kind of drives are probably rarely used. Nevertheless for me, there might also be good reasons not to eject the cartridge in general.
By my feeling these drives are very common in (semi-)professional SOHO environments as external backup devices.
What is the requirement behind it? What is the problem of pressing the eject button?
I would like to show inexperienced users that it is ok to actually remove the cartridge. An ejected cartridge is a clear signal for the user that the backup job is successfully completed.
When the cartridge is ejected when the backup job is done it is no longer possible to store another job on the same cartridge. Or is the RXD drive able to feed-in the tape automatically when a mount command is executed?
Well but it is possible to just re-insert the cartridge again which would trigger a new job, isn't it?
The only problem is that if you reboot the system with a plugged device the rsync job is triggered automatically by UDEV and ejects the device after the sync (incl. removing the device node), which makes it impossible to run the jobs from the UI again. Another problem is when you want to add additional jobs when there are existing jobs. In that case you plug the device, the jobs are running and on success the device node is removed. Because of that the UI will never be able to let the user choose the USB device in the job creation dialog because the device node does not exist anymore.
Therefore, it would be nice to have the option to configure the eject command after the rsync job finished, not as default behavior.
Thx!
PS: Whatever at the end your decision might be - thx a lot for this interesting discussion!
Therefore, it would be nice to have the option to configure the eject command after the rsync job finished, not as default behavior.
That does not fix the problem. If there is one active job for a USB device and you select the eject feature (provided there is a switch in the UI), you will never be able to add additional jobs for that device because the device node is auto-removed after the device is plugged and the rsync jobs were executed. And if you want to add additional jobs in the UI using that device you NEED to plug the device to allow OMV to detect it and show it in the UI in the 'Create job' dialog.
The workaround to disable all active jobs, apply the changes and then plug the device to create new jobs is a really bad solution which you cannot convey to the user. Alternativelly you need to delete all jobs, apply the changes and re-create them from scratch for the given device; this is also no solution. So at the moment i do not see a way how to implement that.
If there is a way to eject the tape without removing the device node, then this will be the solution. But i have no device for evaluating and testing the sysfs capabilities, so any help from the community is welcome. In the meanwhile i let the PR open for comments.
Does the command
# echo 'offline' > /sys/block/sd<X>/device/stateeject the tape? Does the device node still exist after that command?
# cat /proc/partitions | grep sd<X>That does not fix the problem. If there is one active job for a USB device and you select the eject feature (provided there is a switch in the UI), you will never be able to add additional jobs for that device because the device node is auto-removed after the device is plugged and the rsync jobs were executed. And if you want to add additional jobs in the UI using that device you NEED to plug the device to allow OMV to detect it and show it in the UI in the 'Create job' dialog.
The workaround to disable all active jobs, apply the changes and then plug the device to create new jobs is a really bad solution which you cannot convey to the user. Alternativelly you need to delete all jobs, apply the changes and re-create them from scratch for the given device; this is also no solution. So at the moment i do not see a way how to implement that.
OK. I tested a bit. The drive behaves exactly like a USB thumb drive for example. Ejecting the cartridge is the same as unplugging the USB thumb drive. Yet it makes no difference, whether I use the button of the drive to eject it or the eject command. In both cases there is no device and no device node anymore which is expected and logical behavior in my opinion.
As soon as I put the cartridge back in again, the device is there again. No need to actually plug the whole drive. Again exactly the same behavior as with a USB thumb drive.
Does the command
Code# echo 'offline' > /sys/block/sd<X>/device/stateeject the tape? Does the device node still exist after that command?
Code# cat /proc/partitions | grep sd<X>
This command does not eject the cartridge. Device node does still exists.
If there is a way to eject the tape without removing the device node, then this will be the solution. But i have no device for evaluating and testing the sysfs capabilities, so any help from the community is welcome. In the meanwhile i let the PR open for comments.
I don't think that it is possible to eject the cartridge without removing the device node. This indeed makes no sense.
I can only edit the backup job if the device is plugged in and online which is ok for me.
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!