Menu
▾
▴
[Bacula-bugs] [bacula 0001608]: btape failes to test tape if when filemark is inserted by block-driver in test
|
From: Mantis B. T. <no...@bu...> - 2010-07-14 11:32:27
|
The following issue has been REOPENED. ====================================================================== http://bugs.bacula.org/view.php?id=1608 ====================================================================== Reported By: wgstuken Assigned To: ====================================================================== Project: bacula Issue ID: 1608 Category: btape Reproducibility: always Severity: major Priority: normal Status: feedback ====================================================================== Date Submitted: 2010-07-14 08:51 BST Last Modified: 2010-07-14 12:32 BST ====================================================================== Summary: btape failes to test tape if when filemark is inserted by block-driver in test Description: The config value "Maximum File Size" for SD defines boundary at that write_block_to_dev() automatically inserts a Filemark on the tape. When rereading the written test data, btape.c calls read_block_from_device(). This routine doesn't take care of these inserted Filemarks! So the reread-test fails when the first automatically inserted filemark is reached. This only happens if the 10000 * <tape-block-size> is larger than the configured value. For us on a VXA tape <tape-block-size> is 245760 bytes and "Maximum File Size" is 1073741824 (1GB). This bug is not OS-related and not TAPE-type-related. ====================================================================== ---------------------------------------------------------------------- (0005486) kern (administrator) - 2010-07-14 10:31 http://bugs.bacula.org/view.php?id=1608#c5486 ---------------------------------------------------------------------- We do not support NetBSD because to the best of my knowledge they have never had a tape driver that has sufficient functionality to support Bacula. In any case, this is a support request. Bacula works perfectly well on Solaris, Linux, and FreeBSD systems. Despite what you assert with exclamations, Bacula does handle file marks. If your OS does them different from the standard Bacula Device configuration, then you must reconfigure it to correspond to your OS. This problem is most likely OS related, and possibly also tape brand related. It is quite possible that if NetBSD does not behave like Solaris or Linux, it may behave a bit like FreeBSD, which requires some changes to the Bacula SD Device resource to function correctly. This is up to you to resolve, as we don't provide support, and unfortunately, Device configuration for non-standard OSes is one of the more difficult tasks in Bacula. You would probably be much better off running at least the SD on a Linux or FreeBSD OS. ---------------------------------------------------------------------- (0005487) wgstuken (reporter) - 2010-07-14 11:10 http://bugs.bacula.org/view.php?id=1608#c5487 ---------------------------------------------------------------------- Hi, again. The only restriction the (unmodified) NetBSD kernel and tape driver have are related to the internal setting of MAXPHYS in NetBSD - so tape blocks larger than 64k does not work as expected. I aggree that the tape driver in NetBSD is broken if you use blocks larger than 64k. Everything else works fine - up to now. The reported issue is a Bug in btape or in the SD at all! While writeing to the tape when "Maximum File Size" is set to something different as 0, filemarks are inserted in "block.c". When dooing a "normal" tape-reading, filemarks are ignored by the SD-program by just starting the next read operation on EOF until EOT. "But btape" does not honor the inserted filemarks from "block.c" and failes with an error on the first filemark. There are two possible ways to fix this - from my point of view.: 1. fix btape.c to accept the inserted filemarks from "block.c" too. 2. correct read_block_from_device() in "block.c", so that any inserted filemark due to the setting of "Maximum File Size" during write operation is removed silently and not reported to the caller. Both versions have pro and contras: 1 pro: no change in "normal" operation of SD. 1 contra: btape must know something about config variables that it should not know or will accept any filemark from the tape as the SD does. 2. pro: one central place for "hidden-filemark" managment 2 contra: changing "Maximum file Size" in the config file break reading of tapes written with a different setting. ---------------------------------------------------------------------- (0005488) kern (administrator) - 2010-07-14 11:35 http://bugs.bacula.org/view.php?id=1608#c5488 ---------------------------------------------------------------------- What you are claiming is not at all true, when btape is running the "test" command, it uses the exact same routines as the SD except in certain low level routines that are designed to be raw interfaces to the system. Your suggestions for fixes are not something that are acceptable. We are not going to modify Bacula to automatically handle what you call "hidden filemarks" as that would be catastrophic. Bacula can be configured (by you) to handle any reasonable tape driver. I have already explained to you what the problems are and that we don't support NetBSD nor do we give support which is what your request is. Please do not reopen this bug report. ---------------------------------------------------------------------- (0005489) wgstuken (reporter) - 2010-07-14 12:32 http://bugs.bacula.org/view.php?id=1608#c5489 ---------------------------------------------------------------------- Hi again. You still don't get the point that the problem will happen on all operating systems with any kind of tape device that writes filemarks!!!!!!! Are you willing to accept this major bug in bacula's "btape" program as bug report if I install e.g. a linux on one of our spare systems, and send the report again from there? (I've no spare SCSI-Bus on one of our Sun's available ...) It is fact, that bacula will insert "hidden" filemarks while writeing to the device in "block.c", if the written amount of data exceed the setting of "Maximum File Size". It is also fact, that the routine used by SD to read in tapes will ignore all filemarks on the tape till EOT. (see stored/read_record.c function read_records()). Bacula's SD is handling "hidden" filemarks by inserting them during write and simply ignoreing any filemarks while reading from tape! So I don't request any new functionality! And I also don't request to change the behaviour of SD to ignore any filemarks! (This is a valid aproch in order to support changing the "Maximum File Size" setting without affecting old backup tapes.) I just request to change btape.c to honor the things done by the code in block.c. The test routine must either also ignore all filemarks (as done in read_record.c) or must track the amount of data read from the device and accept the hidden filemarks written by the code in block.c at the "Maximum File Size" boundaries. I hope this don't get closed again without any reflection on the contents of this report. Issue History Date Modified Username Field Change ====================================================================== 2010-07-14 08:51 wgstuken New Issue 2010-07-14 10:31 kern Note Added: 0005486 2010-07-14 10:31 kern Status new => closed 2010-07-14 10:31 kern Resolution open => no change required 2010-07-14 11:10 wgstuken Note Added: 0005487 2010-07-14 11:10 wgstuken Status closed => feedback 2010-07-14 11:10 wgstuken Resolution no change required => reopened 2010-07-14 11:35 kern Note Added: 0005488 2010-07-14 11:35 kern Status feedback => closed 2010-07-14 11:35 kern Resolution reopened => won't fix 2010-07-14 12:32 wgstuken Note Added: 0005489 2010-07-14 12:32 wgstuken Status closed => feedback 2010-07-14 12:32 wgstuken Resolution won't fix => reopened ====================================================================== |