From 870adfc3f9654fd7054ddb60024ddd823f0acc5d Mon Sep 17 00:00:00 2001 From: Kern Sibbald Date: Tue, 26 Jul 2005 16:40:02 +0000 Subject: [PATCH] Updates --- docs/home-page/news.txt | 64 +++++++++++++++++++++ docs/home-page/pages/documentation.php | 11 +++- docs/manual/storedconf.tex | 17 ++---- docs/manual/tapetesting.tex | 77 ++++++++++++++++++++++++++ 4 files changed, 154 insertions(+), 15 deletions(-) diff --git a/docs/home-page/news.txt b/docs/home-page/news.txt index b01d115b..00eea323 100644 --- a/docs/home-page/news.txt +++ b/docs/home-page/news.txt @@ -1,3 +1,67 @@ +Kern;;;2005/07/26;;;14:30 +BACULA COMMUNITY NEWS RELEASE +Backup Data Encryption Development Project +26 July 2005 + +WHAT +After initial discussions between Bacula project manager Kern +Sibbald, freelance open source developer Landon Fuller, and Craig +Thompson, President of WingNET Internet Services, an agreement +has been reached to begin work on the inclusion of data +encryption as an integral part of Bacula. + +WHY +The purpose of this project is to provide backup clients with the +ability to securely encrypt their data for storage on Bacula +storage servers without having to worry about the possibility of +the data being accessed either by hackers or third parties. Data +that is encrypted on Volumes on the remote server can give your +customer (or CEO) an additional peace of mind that makes the +difference between a sale or no sale. + +WHO +WingNET recently expressed an interest in seeing this +functionality developed. The concept had also been requested by +numerous individuals and companies in the recent past on the +various Bacula mailing lists. Kern suggested asking Landon to +work on the project in order to speed up the process. + +HOW +Landon Fuller has agreed to begin working on the project. As +compensation for his time, his goal is to raise approximately +$3,000 for donation to the Electronic Freedom Foundation. +WingNET has offered to provide an initial donation of $500 for +the project. However, YOUR support is needed to make the project +a success. The data encryption project needs individuals and +companies who would be willing to donate any amount of money +toward the completion of the project. + +WHERE +You may contribute by going to the EFF site donation page at: + +https://secure.eff.org/site/SPageServer?pagename=DON_splash&JServSessionIdr006=h0do7dkvl1.app2a + +and clicking on the "Gift Memberships >>" button. You will be +asked to provide "Tribute Information" and to select an eCard +recipient. Please use "The Bacula Project" as the honored +individual name, and please choose to send an eCard, including +the amount, to Kern Sibbald . It is not +necessary to specify a snail-mail notification address. + +By correctly sending an eCard, including the donation amount, we can +track the total amount donated for this project. + +Can your company contribute $250 or $500? How about $100? And +if your budget is really tight, why not forego a couple of fast +food meals and contribute $20? + +This is a community project, and this can be your way of helping make +Bacula an even better product for the good of the whole community. + +If you have any questions related to this project, please contact +Kern Sibbald . + + Kern;;;2005/04/26;;;12:00 The Bacula Version 1.36.3 tar file is released to Source Forge. diff --git a/docs/home-page/pages/documentation.php b/docs/home-page/pages/documentation.php index 820c4acc..c667cf47 100644 --- a/docs/home-page/pages/documentation.php +++ b/docs/home-page/pages/documentation.php @@ -45,6 +45,14 @@ + +   + + +  
    @@ -54,9 +62,6 @@
    (Guide for Bacula developers)
- -   -

diff --git a/docs/manual/storedconf.tex b/docs/manual/storedconf.tex index b74d1af9..93c070b6 100644 --- a/docs/manual/storedconf.tex +++ b/docs/manual/storedconf.tex @@ -589,15 +589,11 @@ bacula-sd Alert: TapeAlert[32]: Interface: Problem with SCSI interface Default setting for Hardware End of Medium is {\bf Yes}. This function is used before appending to a tape to ensure that no previously written data is - lost. We recommend if you have a non standard or unusual tape drive that you + lost. We recommend if you have a non-standard or unusual tape drive that you use the {\bf btape} program to test your drive to see whether or not it supports this function. All modern (after 1998) tape drives support this feature. - If you set Hardware End of Medium = no, you should also set {\bf Fast Forward - Space File = no}. If you do not, Bacula will most likely be unable to - correctly find the end of data on the tape. - \item [Fast Forward Space File = {\it Yes|No}] \index[sd]{Fast Forward Space File } If {\bf No}, the archive device is not required to support keeping track of @@ -609,10 +605,7 @@ bacula-sd Alert: TapeAlert[32]: Interface: Problem with SCSI interface but they do not keep track of the file number or more seriously, they do not report end of meduim. - Default setting for Fast Forward Space File is {\bf Yes}. If you disable - Hardware End of Medium, most likely you should also disable Fast Forward - Space file. The {\bf test} command in the program {\bf btape} will test this - feature and advise you if it should be turned off. + Default setting for Fast Forward Space File is {\bf Yes}. \item [Use MTIOCGET = {\it Yes|No}] \index[sd]{Fast Forward Space File } @@ -621,9 +614,9 @@ bacula-sd Alert: TapeAlert[32]: Interface: Problem with SCSI interface is {\bf Yes}. If you must set this to No, Bacula will do the proper file position determination, but it is very unfortunate because it means that tape movement is very inefficient. - Fortunately, this operation system deficiency seems to be the case only on - a few *BSD systems. Operating systems known to work correctly are Solaris, Linux - and FreeBSD. + Fortunately, this operation system deficiency seems to be the case only + on a few *BSD systems. Operating systems known to work correctly are + Solaris, Linux and FreeBSD. \item [BSF at EOM = {\it Yes|No}] \index[sd]{BSF at EOM } diff --git a/docs/manual/tapetesting.tex b/docs/manual/tapetesting.tex index 4e0e67ae..e8ed0ac0 100644 --- a/docs/manual/tapetesting.tex +++ b/docs/manual/tapetesting.tex @@ -1030,6 +1030,83 @@ assumes that each write causes a single record to be written, and that it can sequentially recover each of the blocks it has written by using the same number of sequential reads as it had written. +\subsection*{Details of Tape Modes} +\index[general]{Modes!Details} +\index[general]{Details of Tape Modes } +\addcontentsline{toc}{subsection}{Details of Tape Modes} +Rudolf Cejkar has provided the following information concerning +certain tape modes and MTEOM. + +\begin{description} +\item[Tape level] + It is always possible to position filemarks or blocks, whereas + positioning to the end-of-data is only optional feature, however it is + implemented very often. SCSI specification also talks about optional + sequential filemarks, setmarks and sequential setmarks, but these are not + implemented so often. Modern tape drives keep track of file positions in + built-in chip (AIT, LTO) or at the beginning of the tape (SDLT), so there + is not any speed difference, if end-of-data or filemarks is used (I have + heard, that LTO-1 from all 3 manufacturers do not use its chip for file + locations, but a tape as in SDLT case, and I'm not sure about LTO-2 and + LTO-3 case). However there is a big difference, that end-of-data ignores + file position, whereas filemarks returns the real number of skipped + files, so OS can track current file number just in filemarks case. + +\item[OS level] + Solaris does use just SCSI SPACE Filemarks, it does not support SCSI + SPACE End-of-data. When MTEOM is called, Solaris does use SCSI SPACE + Filemarks with count = 1048576 for fast mode, and combination of SCSI + SPACE Filemarks with count = 1 with SCSI SPACE Blocks with count = 1 for + slow mode, so EOD mark on the tape on some older tape drives is not + skipped. File number is always tracked for MTEOM. + + Linux does support both SCSI SPACE Filemarks and End-of-data: When MTEOM + is called in MT_ST_FAST_MTEOM mode, SCSI SPACE Filemarks with count = + 8388607 is used. In the other case, SCSI SPACE End-of-data is used. + There is no real slow mode like in Solaris - I just expect, that for + older tape drives Filemarks may be slower than End-of-data, but not so + much as in Solaris slow mode. File number is tracked for MTEOM just + without MT_ST_FAST_MTEOM - when MT_ST_FAST_MTEOM is used, it is not. + + FreeBSD does support both SCSI SPACE Filemarks and End-of-data, but when + MTEOD (MTEOM) is called, SCSI SPACE End-of-data is always used. FreeBSD + never use SCSI SPACE Filemarks for MTEOD. File number is never tracked + for MTOED. + +\item[Bacula level] + When {\bf Hardware End of Medium = Yes} is used, MTEOM is called, but it + does not mean, that hardware End-of-data must be used. When Hardware End + of Medium = No, if Fast Forward Space File = Yes, MTFSF with count = + 32767 is used, else Block Read with count = 1 with Forward Space File + with count = 1 is used, which is really very slow. + +\item [Hardware End of Medium = Yes|No] + The name of this option is misleading and is the source of confusion, + because it is not the hardware EOM, what is really switched here. + + If I use Yes, OS must not use SCSI SPACE End-of-data, because Bacula + expects, that there is tracked file number, which is not supported by + SCSI specification. Instead, the OS have to use SCSI SPACE Filemarks. + + If I use No, an action depends on Fast Forward Space File. + + Considering {\bf Hardware End of Medium = no} + and {\bf Fast Forward Space File = no} + When I set the two to no, file positioning was very slow + on my LTO-3: +\begin{verbatim} + HEOM = no, FFSF = no: ~ 10 - 100 minutes +\end{verbatime} + +while even with {\bf Hardware End of Medium = no} but +{\bf Fast Forward Space File = yes}, the time is 10 to +100 times faster. +\begin{verbatim} + HEOM = no, FFSF = yes: ~ 1 minute +\end{verbatim} + +\end{description} + \subsection*{Autochanger Errors} \index[general]{Errors!Autochanger } \index[general]{Autochanger Errors } -- 2.39.5