Re: [Bacula-users] Building bacula on OpenBSD
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
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
