Phil Stracchino <[EMAIL PROTECTED]> writes:
>> I don't know. It's almost like it's trying to mount the disc and,
>> failing, assumes it can't access the disc. If it fails it should assume
>> that it's a non-formatted disc, shouldn't it? Can you mount a blank
>> disc under Linux?
>
> No, you can't. Remember that you mount filesystems, not devices. You
> cannot mount (from the shell) a blank disk that doesn't have a
> filesystem on it, because there's no filesystem to mount.
That's true, but apparently whoever wrote dvd.c hadn't heard that, because
the DVD code in the SD sure *does* try to mount a blank disk when you go
to label it, and objects when the moutn fails. I'm guessing that maybe
Linux /sbin/mount doesn't return a non-zero error code when it fails.
FreeBSD's /sbin/mount does.
Having just upgraded to CVS head bacula on my FreeBSD box and gotten the
newfangled DVD writing code working and succesfully backing up my data,
I can explain what I had to do to get things working. (Things should be
about the same on 1.38.3beta; I started with that, and when I ran into
weird behavior switched to the CVS head in hopes the weird behavior wouldn't
be there. It was.) This is on FreeBSD-current, if that matters.
Here's the relevant section from bacula-sd.conf:
Device {
Name = "DVD"
Media Type = DVD
Archive Device = /u2/BaculaDVD/fakedevicefile
LabelMedia = yes; # lets Bacula label unlabeled media
Random Access = Yes;
AutomaticMount = yes; # when device opened, read it
RemovableMedia = yes;
AlwaysOpen = no;
MaximumPartSize = 800M;
RequiresMount = yes;
MountPoint = /u2/BaculaDVD/mnt;
# MountCommand = "/sbin/mount -t cd9660 -o ro /dev/cd1 %m";
MountCommand = "/usr/local/etc/bacula-stuff/mountcd.sh %m";
# UnmountCommand = "/sbin/umount %m; exit 0";
UnmountCommand = "/usr/local/etc/bacula-stuff/unmountcd.sh %m";
SpoolDirectory = /u2/BaculaDVD/NewSpool;
WritePartCommand = "/usr/local/share/bacula/dvd-handler /dev/cd1 write %e %v"
FreeSpaceCommand = "/usr/local/share/bacula/dvd-handler /dev/cd1 free"
}
and some comments:
1) Note the odd Archive Device line:
Archive Device = /u2/BaculaDVD/fakedevicefile
There's a reason for this. When Bacula SD initializes its devices, it stats()
the device to figure out what kind of device it is. If it's a character
device, it sets the ST_TAPE flag. Problem is, FreeBSD is a little unusual
in that, unlike older Unixes, there *is* no such thing as a block device
anymore, so /dev/cd1 is a character device. See?
10 ichotolot ~[12:21AM] Z% ls -l /dev/cd1
crw-r----- 1 root operator 0, 116 Dec 24 23:55 /dev/cd1
So if you specify the real CD drive name on the Archive Device line, Bacula
sees the char. device and assumes it's a tape, causing Massive Confusion when
it then tries to rewind it. :-) Since all the real work in writing to or
mounting the DVDs is done by auxiliary scripts, Bacula doesn't really *need*
to know the DVD drives device name, so I create a zero-length file and set
that as Archive Device, and hardwire in /dev/cd1 in WritePartCommand and the
like.
2) As I mentioned before, when you try to label blank media, Bacula tries to
mount the blank DVD, the mount fails, and SD complains loudly. We work around
this by not having MountCommand call mount directly, but call a shell script
that calls mount and always "exit 0"s:
13 ichotolot ~[12:26AM] Z% cat /usr/local/etc/bacula-stuff/mountcd.sh
#!/bin/sh
/sbin/mount -t cd9660 -o ro /dev/cd1 $1
exit 0
The unmountcd.sh script is very similar.
3) When you go to label a DVD, the SD mounts the DVD and calls
check_can_write_on_non_blank_dvd to, I guess, see if you're trying to label
a DVD that's already been used by Bacula and has backups on it. It does
so by opendir()ing the mount directory and seeing how many files there are;
if it gets a number different than 3, it tells the caller to abort the
attempt at labelling this DVD. Why 3? I wish I knew. The problem is, when
labeling a blank DVD, the mount fails (silently, since we forced it to lie
about its exit code with the mountcd.sh hack above), /u2/BaculaDVD/mnt is
empty so only has "." and "..", so the function declares an error. I'm
not really sure this is the correct patch, since I don't fully understand the
intent of the original code, but this is what I did to get things working:
--- src/stored/dvd.c.orig Sat Dec 17 20:18:29 2005
+++ src/stored/dvd.c Sat Dec 17 20:19:09 2005
@@ -822,6 +822,7 @@
closedir(dp);
Dmsg2(29, "check_can_write_on_non_blank_dvd: got %d files in the mount
point (matched=%d)\n", count, matched);
+ if (count == 2) return true;
if (count != 3) {
/* There is more than 3 files (., .., and the volume file) */
4) Once you've got all that done, DVD backups work just fine, with one
minor exception. If you look at the dvd-handler script and the
growisofs docs, you'll know that there's an issue on some systems with
being able to read DVDs where one of the sessions has a start location
past the 4GB mark. growisofs by default doesn't try to write such a session
unless you pass it a certain flag. dvd-handler checks to see if you're on
Linux and if you're on a new enough version of Linux, enables post-4GB
sessions, otherwise not. *But*, on non-Linux systems, dvd-handler assumes
you can handle post-4GB sessions and enables them. At least on FreeBSD,
this is a bad assumption. The way I know this is a bad assumption is that
when you try to mount a DVD created when Bacula had to start a new part on
the DVD out past the 4GB mark, the kernel spews the following cryptic
message:
Dec 21 10:50:22 ichotolot kernel: RRIP without PX field?
and ls on the mounted DVD doesn't show any files. (Eek!) Fortunately, these
post-4GB sessions only seem to confuse the Rock Ridge code in the kernel, not
the ISO9660, so you can fix one of those "bad" DVDs by doing the following:
1) Mount the DVD with Rock Ridge disabled. The files will all show up
then, just with ISO-mangled names.
2) Copy the files to a temp area.
3) Rename the files to their original names.
4) Use growisofs to wipe the DVD and rewrite the data files all in one
session.
But it's best not to create such DVDs if one can help it. The default on
dvd-handler should probably be to *not* assume post-4GB session capability
unless you're on an OS version that's *known* to work with it.
With all the above caveats/patches, Bacula DVD writing is working for me
on FreeBSD, and I did 60GB of Full backups with it this week.
-------------------------------------------------------
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://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
