Re: [Bacula-users] Building bacula on OpenBSD

2007-04-10 Thread Kern Sibbald
On Tuesday 10 April 2007 15:52, Brian A. Seklecki wrote:
 It looks like some significant improvements have been made to st(4):
 
 http://www.openbsd.org/plus41.html
 
 Make the st(4) SCSI Tape midlayer return values when receiving a
 MTIOCGET ioctl, allows things like Bacula to work much

Nice.

 
 http://www.openbsd.org/cgi-bin/cvsweb/src/sys/scsi/st.c
 
 Thank you for all who contributed to that.  Should we return attention
 to getting a comprehensive Bacula port committed?

Normally, there should be nothing to do other than build Bacula on OpenBSD. 
Now that MTIOCGET has mt_blkno and mt_fileno defined there should be no major 
obstacles. 

Then try running btape.

 
 ~BAS
 
 On Fri, 2006-12-22 at 19:09 +0100, Kern Sibbald wrote:
  On Sunday 17 December 2006 18:45, Kenneth Westerback wrote:
   Thanks for bringing this discussion to my attention Russell. If someone
   can point me at the standard or other justification a 'Unix' system
   requiring mt_blkno and mt_fileno in the mtget structure I'd be more than
   happy to put them back. I would be even happier if someone could direct
   me to a discussion on what the mandated or recommended action is for
   these fields when the OS cannot supply any meaningful information. I
   note that HPUX seems to always put -1 in them.
  
  Well, the best justification for a Unix standard would be Posix, but 
  unfortunately Posix (at least my somewhat old Posix book) does not talk 
about 
  tape operations.
  
  However, FreeBSD, Linux, and Solaris all support MTIOCGET with the 
mt_fileno 
  and mt_blkno fields in the packet.  On some OS the values returned may not 
be 
  valid, or may not be valid under certain circumstances (e.g. backspace 
record 
  or backspace file or space to end of medium).  Bacula's tape driver 
  references both mt_fileno and mt_blkno and thus if they do not exist, the 
  Storage daemon (tape driver part will not compile).  However, the user can 
  configure his Bacula driver (in bacula-sd.conf) to essentially not do or 
  ignore the values returned from MTIOCGET.  Doing so makes tape operations 
  painfully slow because Bacula must simulate what the kernel SCSI driver 
can 
  do much more efficiently.
  
  Setting mt_fileno and mt_blkno to -1 indicates to any tape I/O aware 
program 
  such as Bacula that the value is unknown to the SCSI driver, and the 
program 
  must take appropriate action ...  as a consequence, I would see no great 
harm 
  in defining those fields and always returning -1 in them.  Doing so, would 
  probably also permit additional Open Source to compile and run on OpenBSD 
  without specific OpenBSD #ifdefing.  
  
  Whatever the case may be, the Bacula tape driver already has a lot of 
  #ifdefing in it to adapt to different systems, so I wouldn't be very 
inclined 
  to #ifdef it so that it does not reference mt_fileno and mt_blkno unless 
  there were several systems that needed such a change.
  
   
    Ken
   
   Kenneth R Westerback
   Technology Architect, Corporate Resources
   
   St. Michael's Hospital
   30 Bond Street
   Toronto, Ontario
   M5B 1W8
   
   Office: 416-864-5981
   
   e-Mail: [EMAIL PROTECTED] 
   www.stmichaelshospital.com 
   
   This message may contain privileged and confidential information and is
   intended solely for the use of the intended recipient. If you are
   neither the intended recipient nor the employee or agent responsible for
   delivering this communication to the intended recipient, you are hereby
   notified that any disclosure, copying or distribution of, or the taking
   of any action in reliance on the contents of this communication is
   strictly prohibited. If you have received this communication in error,
   please notify us immediately by e-Mail at [EMAIL PROTECTED]
   or telephone at 416-864-5981. Thank you.
Russell Sutherland [EMAIL PROTECTED] 12/16/06 9:38 AM 
   Here's a note that I received from Ken Westerback, some weeks ago
   and his take on why these two variables were removed
   from the include file:
   
   http://www.openbsd.org/cgi-bin/cvsweb/src/sys/sys/mtio.h
   
   It would appear I removed them since they are not implemented, as of
   r1.7. I think leaving them in but unimplemented is just misleading.
   Software  that does not function in the absence of this information will
   be more readily identified if it can't compile. :-).
   
   I guess you can add them back to get the compile working, or patch
   bacula to not touch them. If you have some strong reasons for adding
   them back to the standard system I'm willing to listen.
   
    Ken
   
   
   Kenneth R Westerback
   Technology Architect, Corporate Resources
   
   St. Michael's Hospital
   30 Bond Street
   Toronto, Ontario
   M5B 1W8
   
   Office: 416-864-5981
   
   e-Mail: [EMAIL PROTECTED]
   www.stmichaelshospital.com
   
   On 13/12/06, Kern Sibbald [EMAIL PROTECTED] wrote:
Hello,
   
Since this is directed to me, and assuming I wrote the double 'ed

Re: [Bacula-users] Building bacula on OpenBSD

2006-12-13 Thread Kern Sibbald
Hello,

Since this is directed to me, and assuming I wrote the double 'ed sections 
below (which sound a lot like me but so much is snipped that I cannot be 
sure), I can assure you that, my intention, if I am the guity party was not 
to insult any person or any particular OS, but just to point out that it 
appears to me to be an OS compatibility problem (actually a system header 
file to be more correct).

See notes below, where I assume that I wrote the offending statements:

On Wednesday 13 December 2006 18:28, Brian A. Seklecki wrote:
   Stop in /usr/local/src/bacula-1.38.11/src/stored.
  
  It looks to me like the OS' header file is badly broken -- at least in the 
  sense that if it is a Unix system, both mt_fileno and mt_blkno should be 
  defined in the struct mtget.
  
  Someone should fix the OS, barring that we will need a patch.
 
 Kern, Rus, et al:
 
 We have to be really careful with regard how we word things here.  The
 way you assert that could be easily misinterpreted or misconstrued to
 have a vendor-bashing tone.

I'm sorry, I did not intend to be vendor bashing.  I stand by what is written. 
If it is a Unix system and there are not mt_fileno and mt_blkno in the struct 
mtget, there are serious compatibility problems, since I don't have an 
OpenBSD system, assuming the OS is not going to change, we would need a patch 
to Bacula to fix it.

 
 Moreover, conceding the unavailability of compatibility with the OpenBSD
 platform doesn't gain us any additional users; a very large group of
 talented individuals with tremendous experience writing highly secure,
 reliable, and _portable_ code who could contribute greatly to the
 project.
 
 -- To set the record straight, and encourage mutual cooperation -- 
 
 The reality here is that OpenBSD is very selective about where it
 focuses its development efforts, and the st(4) driver is not one of
 those places.
 
 Therefore, the assertion that The OS is broken is not correct, it
 simply hasn't been implemented or maintained as it should.

Yes, broken was a poor choice of words.  I would rephrase it to say it is not 
Unix compatible.

 
 Before I go on and make my own silly assertions, I should note: '
 
Things are always subject to change, and this is F/OSS and you're
always welcome to do the work yourself or have corporate sponsorship.
 
 OpenBSD is not the platform for a Bacula director.  You wont see it (at
 present) driving a 5-LTO3-drive, 2000 tape, 1000+ Terabyte StorageTek
 Powderhorn Tape Silo connected via Brocade FC switches.(1)
 
 However you will see it at the perimeter and on the wire keeping the
 packet kiddies from stealing all of your customers data.  It could be
 the ideal system for the job with features like enhanced crypto
 acceleration via crypto(9) and the existing improvements on scsi(4) and
 recent HBA support.
 
 Anyway, not a director, not now at least, and probably not a SD Storage
 Daemon either.

Yes, since the problem above arises when compiling the SD.

 
 But most definitely a management console and file daemon.

I think these already exist.  Bacula does have some code to support OpenBSD.

 
 Russel: You'll probably notice that Bacula builds perfectly fine up
 until it gets to the director, then you get into OS-specific kernel
 knits and hooks where either OpenBSD lacks the framework/API (pthreads,
 st(4), etc.) or kernel-specific code needs to be added to Bacula.

Without a decent implementation of pthreads, even the client (file daemon) 
will not build.

 
 In the mean time, we should endeavor to create a bacula-clientonly
 Port in OpenBSD ports, or bacula port with a clientonly flavor.
 
 This has been done before, but the work was never commited (CC:)
 
 1. http://www.arsc.edu/resources/silo.html
 
 I will take the lead on this if I have to.
 
 ~BAS
 
  
  I checked the man page for st, where all other Unix systems define the 
packet.  
  They include no definition, so you will need to consult the header file 
  directly sys/mtio.h.   Sorry, but you are pretty much on your own on this.
  
  
  
   
   
 == Error in /usr/local/src/bacula-1.38.11/src/stored ==
   
   
   ==Entering directory /usr/local/src/bacula-1.38.11/src/tools
    Make of tools is good 
   
 
 
 
 -
 Take Surveys. Earn Cash. Influence the Future of IT
 Join SourceForge.net's Techsay panel and you'll get the chance to share your
 opinions on IT  business topics through brief surveys - and earn cash
 http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
 ___
 Bacula-users mailing list
 Bacula-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bacula-users