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 rem

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.php&p=sourceforge&CID=DEVDEV
> ___
> Bacula-users mailing list
> Bacula-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bacula-users
>