On Wednesday, July 22, 2015 at 4:35:00 AM UTC-5, philipp.storz wrote:
> After changing the content of the changer, you have to call "update slots",
> This will change the "inchanger" flag of those volumes to 0, so that bareos
> knows they are not in
> the changer.
>
> When trying to find the next appendable volume, bareos always first tries to
> get volumes that are in
> the changer.
FYI, I'm not seeing this behaviour in -current. Bareos is insisting on a
volume I exported today (using the 'export' bconsole command). And yes, I did
an update slots, and InChanger got set to zero.
> What you can also do is configure the "maximum volume use duration" to e.g.
> 23 h, that will
> automatically set the volume to full after that time has passed since the
> first write.
I don't necessarily want to do this; marking it full only takes effect after I
cancel the job that's waiting on the exported volume.
Should I report this as a bug (with full details there), or has something
changed?
I *think* the problem stems from this (from "status jobs"):
====
Used Volume status:
000006L6 on device "tapedrive-tl1000"
(/dev/tape/by-id/scsi-350016977299e1010-nst)
Reader=0 writers=0 reserves=5 volinuse=0
000019L3 on device "tapedrive-pv124t"
(/dev/tape/by-id/scsi-1IBM_ULTRIUM-TD3_1210358856-nst)
Reader=0 writers=0 reserves=0 volinuse=0
====
...but 000006L6 is the volume I exported today! I'm pretty sure I did a
unmount/mount before and after exporting - would forgetting that step cause
this situation?
Thanks,
-Adam
--
You received this message because you are subscribed to the Google Groups
"bareos-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
For more options, visit https://groups.google.com/d/optout.
