Hello,
On Tuesday 17 January 2006 20:35, Josh Fisher wrote:
> I understand your concerns, Kern, but let's look at this from another
> angle. I say it is a delegation of authority issue. You have done such
> excellent work here that I hesitate for fear of stepping on your toes,
> but this is just my thoughts (and I've been wrong many times before).
I've had my toes stepped on so many times now that ususally try to understand
the other guy before getting upset. More often than not, I learn
something :-)
> For disk storage devices bacula should continue to treat the volume as
> a file and nothing more.
Yes, that is exactly my intention -- there are just a few annoying details ...
> It is the operating system's job to abstract
> the physical device issues so that application software can read/write
> to a filesystem and thus be used on any device capable of containing
> that filesystem. In fact, the filesystem itself is abstracted for the
> same reason. Modern devices include removable, hot pluggable disk
> drives. The OS must be able to handle this if it is to be reasonably
> useful with modern storage devices.
>
> Barry will testify that bacula is usable as is with USB devices on a
> Linux system with HAL/udev. I don't know that anyone has tried it yet,
> but the same method should be usable with hot pluggable devices on other
> bus types on Linux as long as HAL/udev can handle them. By sticking with
> treating file-based volumes as simply files, bacula can more easily be
> made to work on any OS, probably even Windows.
>
> I think your concern is "what happens when a USB drive is unplugged
> during a job?".
Well, I wasn't very specific, so sorry for the confusion. I was worried about
the fact that for File storage, Bacula expects the Volumes to be there when
the job starts, and if they are not, it will fail. For removable devices,
Bacula should request that the operator mount the device if it does not find
it -- at least if the user has it configured that way.
> I believe the answer to that is the same as "what
> happens when a SCSI hard drive dies during a job?". And I think the
> answer is that bacula fails the job and changes the volume status to
> "error". I believe that to be the correct behavior AFTER the job has
> already written successfully to the volume at least once. But the
> initial opening of the file at the start of the job needs to be handled
> differently when it fails. For disk storage devices with "Removable
> media = no" it should continue to fail the job as it does now.
Yes,
> For disk
> storage devices with "Removable media = yes"
Well, here you already have a problem. You say "For disk storage devices",
and that is the main problem I was referring to. Currently, Bacula has no
way to know for sure that a device is a "fixed" disk, a CDROM, or what. It
tries to guess, but with some OSes, it is not possible to distinguish a disk
and a CDROM.
> I am imagining the following algorithm:
>
> 1. Attempt to open volume file. If successful then proceed with backup
> as usual.
> 2. Wait some period of time then try the open again (in case automount
> might have mounted an NFS share). If successful then proceed with
> backup as usual.
> 3. Determine if there is a device mounted at the path specified in the
> "Archive device" directive and fail the job if there already is
The problem is that the above is very OS specific, and in general, Bacula has
very little OS specific code, especially "complicated" OS specific code such
as if a device is mounted at the path specified. What does that mean on
Win32?, ...
> 4. Re-queue the job with status "pending user intervention" and inform
> user that device is not mounted at mountpoint
> 5. Fork thread to wait for a device to be mounted at mountpoint
> 6. When device is detected as being mounted at mountpoint resume
> the job at step 1
Basically, what I am going to do is what you suggest except it is going to be
the user who tells me that the device is of type File (or possibly USB) and
that it is removable. In that case, when the volume cannot be opened, either
the user will have specified a mount command (which in fact could be a script
so that it works on Win32), in which case, Bacula will mount the device, or
Bacula will do as you say, ask the user to mount it.
>
> I believe this to be a more general way of handling removable disk
> drives, as well as NFS, smbfs,cifs, etc. mounts. HAL/udev is just a
> convenience. Without it the user would manually mount the device when
> bacula asked for it.
> With HAL/udev the user would simply plug the thing
> in and it would Just Work(tm).
For that to work correctly today with Bacula, each USB disk must have a unique
path, which is probably possible with udev, but certainly not the default.
One of my objectives is to figure out a way so that "multiple" File systems
can be mounted on the same device, much as if you are able to mount multiple
different tapes on a tape drive. The major difference is that a File system
can have multiple Volumes while a tape is by Bacula's definition a single
Volume.
>
> Kern Sibbald wrote:
> >Hello Barry,
> >
> >It is nice to hear this kind of enthousiasm and success !
> >
> >Please when you get it going to your satisfaction, send us the details. I
> > am sure there a lot of users who would like to accomplish the same thing.
> >
> >I'm still concerned about how Bacula is going to deal with directories and
> >volumes that "disappear". In any case, I have my two little 2GB USB
> > devices, and I am going to work over the next months on making Bacula
> > understand what a USB device is and to deal with it in a more reasonable
> > way. To do this, I think there are more than sufficient directives in
> > the Device resource in the SD, with one exception -- most likely I need
> > to add a "Device Type = xxx" directive which could have values such as
> > "Tape, File, DVD, USB, FIFO, ..." Bacula currently "guesses" at what the
> > device type is, and in most cases, it gets it right, but USB vs DVD is
> > not so easy, and on FreeBSD there is no distinction between character
> > devices and block devices.
> >
> >On Saturday 14 January 2006 04:27, Barry L. Bond wrote:
> >>Hey, Kern, Arno and Josh!
> >>
> >> I GOT IT -- I GOT IT -- I GOT IT! :-)
--
Best regards,
Kern
(">
/\
V_V
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
