Jenkins build is still unstable: FreeBSD_HEAD-tests2 #782
See https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests2/782/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: sa(4) driver changes available for test
On Fri, Feb 27, 2015 at 17:56:42 -0500, Dan Langille wrote: On Feb 17, 2015, at 1:36 PM, Kenneth D. Merry k...@freebsd.org wrote: On Sat, Feb 14, 2015 at 18:22:43 -0500, Dan Langille wrote: On Feb 13, 2015, at 7:32 PM, Kenneth D. Merry k...@freebsd.org wrote: I have a fairly large set of changes to the sa(4) driver and mt(1) driver that I'm planning to commit in the near future. A description of the changes is here and below in this message. If you have tape hardware and the inclination, I'd appreciate testing and feedback. I have a DLT 8000 and an SDLT 220. I don't have anything running current, but I have a spare machine which I could use for testing. Do you see any value is tests with that hardware? I'd be testing it via Bacula. disclosure: I'm the sysutils/bacula-* maintainer and a Bacula committer. Actually, yes. Bacula is a bit tricky to configure, so your trying it out would be helpful if you have the time. I have been unable to test yet. I've encountered time and hardware issues. I know how that goes! (On both counts.) I may be able to try tomorrow. So I have tested building it and it does build at least. If you're able to figure out some of the answers below, that would be great! In looking at the manuals for both the SDLT 220 and the DLT 8000, they both claim to support long position information for the SCSI READ POSITION command. You can see what I'm talking about by doing: mt eod mt status On my DDS-4 tape drive, this shows: # mt -f /dev/nsa3 status Drive: sa3: SEAGATE DAT06240-XXX 8071 Serial Number: HJ00YWY - Mode Density Blocksize bpi Compression Current: 0x26:DDS-4 1024 bytes 97000enabled (DCLZ) - Current Driver State: at rest. - Partition: 0 Calc File Number: -1 Calc Record Number: -1 Residual:0 Reported File Number: -1 Reported Record Number: -1 Flags: None But on an LTO-5, which will give long position information, I get: [root@doc ~]# mt status Drive: sa0: IBM ULTRIUM-HH5 E4J1 - Mode Density Blocksize bpi Compression Current: 0x58:LTO-5 variable 384607 enabled (0x1) - Current Driver State: at rest. - Partition: 0 Calc File Number: 2 Calc Record Number: -1 Residual:0 Reported File Number: 2 Reported Record Number: 32373 Flags: None That, in combination with the changes I made to the position information code in the driver, mean that even the old MTIOCGET ioctl should return an accurate file number at end of data. e.g., on the LTO-5: [root@doc ~]# mt ostatus Mode Density Blocksize bpi Compression Current: 0x58:LTO-5 variable 384607 0x1 -available modes- 0:0x58:LTO-5 variable 384607 0x1 1:0x58:LTO-5 variable 384607 0x1 2:0x58:LTO-5 variable 384607 0x1 3:0x58:LTO-5 variable 384607 0x1 - Current Driver State: at rest. - File Number: 2 Record Number: -1 Residual Count -1 So the thing to try, in addition to just making sure that Bacula continues to work properly, is to try setting this for the tape drive in bacula-sd.conf: Hardware End of Medium = yes It looks like the Bacula tape program (btape) has a test mode, and it would be good to run through the tests on one of the tape drives and see whether they work, and whether the results are different before and after the changes. I'm not sure how to enable the test mode. I'll let the other Bacula devs know about this. They deal with the hardware. I work on PostgreSQL. Thanks! If there are additional features they would like out of the tape driver, I'm happy to talk about it. (Or help if they'd like to use the new status reporting ioctl, MTIOCEXTGET or any of the other new ioctls.) Ken -- Kenneth Merry k...@freebsd.org ? Dan Langille http://langille.org/ Ken -- Kenneth Merry k...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
system failure: cannot kill webkit-gtk3 if using dumbell/radeon
I just hit a major kernel bug with the new Radeon code * I'm on dumbbell's patch_38 for world/kernel (11.0-CURRENT #2 45116d3(master)-dirty) * I started www/midori and was getting segfaults with URL that start with h. I re-built midori using WITH_DEBUG=yes, got no output, then re-built without DEBUG enabled because I was having image display problems. Reported the problem as port issue: http://freebsd.1045724.n5.nabble.com/www-midori-dislikes-the-letter-h-td5992424.html * At some point while using Midori (and right after I logged into Facebook) sytem started to hiccup and slow down, so I swithced to tty*. I start X.org with startx, so I tried to kill X with ctr+c no response. Here's where it gets interesting. Each step indicated with * was done on different tty, all tty's were logged in as root: * issue # top tty froze, does not exit. * Several other simple root-level commands from different TTY result in TTY freeze. * Let's free some RAM: # service kill xyz nothing, no result kill -9 process-name ok jail -r aa bb cc tty freeze * jls jails still running, previous command obviously could not kill let's kill processes: kill -9 process_num_for_midori ok kill -9 process_num_for_several others ok kill -9 process_num_for_WebKitWeb NOPE, DOES NOT KILL * # shutdown now hangs for ever * On TTY1: shows signal 15, but does not proceed. Seems to have difficulty killing jails. ctl+alt+del helps a bit. Shuts down eventually, after appx 10 mins. After restart and in xorg, one cycle of start/stop for Midori does not produce any of symptoms above. When killing WebKitWeb, the higher process_numbers died, but the lower process_numbers resisted. So the spawned processes could be killed, but the master process could not. -- FreeBSD_amd64_11-Current_RadeonKMS ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Current build world failed: bsdxml is missing?
On 27 February 2015 at 18:04, Manfred Antar n...@pozo.com wrote: At 03:51 AM 2/27/2015, Arseny Nasokin wrote: Hi guys, I've found the reason and I've fixed it. The reason is I build world with WITHOUT_DYNAMIC_ROOT option. The library libgeom depends on libbsdxml and libsbuf which will not linked to target program in this case. I have the patch for several programs in sbin and usr.sbin to fix this problem. -- Eir Nym It would be nice if someone fixed this, it's been broken for quit awhile The WITHOUT_DYNAMIC_ROOT option. If I want static root, have to patch a few makefiles in bin and sbin. Thanks || n...@pozo.com || || || Hi, I've created PR 198078 for this particular bug and PR 198079 to add Jenkins target to build WITHOUT_DYNAMIC_ROOT option. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198078 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198079 -- Eir Nym ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: removing _WANT_IFADDR breaks net-snmp
On Thu, Feb 26, 2015 at 10:08:40PM -0500, Michael Butler wrote: M The recent changes which served to hide struct ifaddr have broken M net-snmp: I know and slowly working on that: https://lists.freebsd.org/pipermail/svn-src-head/2015-February/068674.html -- Totus tuus, Glebius. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: system failure: cannot kill webkit-gtk3 if using dumbell/radeon
I see some errors in my last post, correcting: I used # service onestop xyz and NOT # service kill xyz One of the TTY freezes occurred when exiting nano: ctrl+x, y (exit save) -- FreeBSD_amd64_11-Current_RadeonKMS Please include my email when responding (use Reply To All) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Current build world failed: bsdxml is missing?
At 03:51 AM 2/27/2015, Arseny Nasokin wrote: Hi guys, I've found the reason and I've fixed it. The reason is I build world with WITHOUT_DYNAMIC_ROOT option. The library libgeom depends on libbsdxml and libsbuf which will not linked to target program in this case. I have the patch for several programs in sbin and usr.sbin to fix this problem. -- Eir Nym It would be nice if someone fixed this, it's been broken for quit awhile The WITHOUT_DYNAMIC_ROOT option. If I want static root, have to patch a few makefiles in bin and sbin. Thanks || n...@pozo.com || || || ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: FreeBSD FUSE calls truncate() on read-only files
On Fri, 27 Feb 2015, Julian Elischer wrote: for example it caches information when it shouldn't, even from 'dynamic' file systems We had to change the code to disable it as our data is synthetic and might change between reads. fstat info is also cached and confused our apps mightily. You are of course planning to file bug reports about these issues, I presume? -Ben ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: sa(4) driver changes available for test
Bezüglich Kenneth D. Merry's Nachricht vom 26.02.2015 23:42 (localtime): … And (untested) patches against FreeBSD stable/10 as of SVN revision 278974: http://people.freebsd.org/~ken/sa_changes.stable_10.20150218.1.txt … I'm glad it is working well for you! You can do larger I/O sizes with the Adaptec by changing your MAXPHYS and DFLTPHYS values in your kernel config file. e.g.: options MAXPHYS=(1024*1024) options DFLTPHYS=(1024*1024) If you set those values larger, you won't be able to do more than 132K with the sym(4) driver on an x86 box. (It limits the maximum I/O size to 33 segments * PAGE_SIZE.) Thanks for the hint! I wasn't aware that kern.cam.sa.N.maxio has driver limitations corresponding to systems MAX/DFLTPHYS. I thought only silicon limitations define it's value. But in order to have a best matching pre-production test-environment, I nevertheless replaced it, now using mpt(4) instead of ahc(4)/ahc_pci on PCI-X@S3210 (for parallel tape drives I consistently have mpt(4)@PCIe, which is the same LSI(53c1020) chip but with on-board PCI-X-PCIe bridge). Still just works fine ! :-) (stable_10.20150218.1-patchset with LTO2, LTO3 and DDS5) With DDS5, densitiy is reported as unknown. If I remember correctly, you have your DDS4 reporting DDS4? therefore I'd like to point to the new port misc/vdmfec https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197950 That looks cool. :) I'm not a ports committer, but hopefully one of them will pick it up. Cool it is indeed, but whether it's really usefull or not is beyond my expertise. I couldn't collect much MT experience yet. I know that LTO and similar modern MT technology do their own ECC (in the meaning of erasure code, mostly Reed-Solomon). What I don't know (but wanting to be best prepared for) is how arbitrary LTO drives behave, if the one (1) in 10^17 bits was detected to be uncorrectable. If it wasn't detected, the post erasure code (vdmfec in that case) would help for sure. But If the drive just cuts the output, or stops streaming at all, vdmfec was useless… According to excerpts of Study of Perpendicular AME Media in a Linear Tape Drive, LTO-4 has a soft read error rate of 1 in 10^6 bits and DDS has 1 in 10^4 bits (!!!, according to HP C1537A DDS 3 - ACT/Apricot). So with DDS, _every_ single block pax(1) writes to tape needs to be internally corrected! Of course, nobody wants zfs' send output stream to DDS, it's much too slow/small, but just to mention. For archives of zfs streams, I don't feel safe relying on the tape drives' FEC, which was designed for backup solutions which do their own blocking+cheksumming, so the very seldom to expect uncorrectable read error would at worst lead to some/single unrecoverable files – even in case of database files most likely post-recoverable. But with one flipped bit in the zfs stream, you'd loose hundred of gigabytes, completely unrecoverable! As long as the tape keeps spitting complete blocks, even in the case when the tape knows that the output is not correct, vdmfec ought to be the holy grail :-) Going slightly more off topic: One hot candidate for beeing another holy grail, is mbuffer(1) for me. I don't know if tar/pax/cpio do any kind of FIFO buffering at all, but for zfs-send-streaming, mbuffer(1) is obligatory. Even with really huge block sizes, you can't saturate LTO-3 native rate. With mbuffer(1) it's no problem to stream LTO-4 native rate with a tape-transport-blocksize of 32k. Btw, besides the FIFO-buffering, I'm missing star(1) also for it's multi-volume support. tar(1) in base isn't really useful for tape buddies – IMHO it's hardly adequate for any purpose and I don't understand it's widespread usage… Most likely the absence of dump(8) for zfs misleads to tar(1) ;-) Were there ever thoughts about implementing FIFO-buffering into sa(4)? We don't have mbuffer(1) in base, but I think, to complete FreeBSD's tape support, users should find all technology/tools, needed for using modern tape drives, in base. If sa(4) could provide sysctl-controlled FIFO-buffering, some base tools were a bit more apropriate for tape usage, I think. Thanks, -Harry signature.asc Description: OpenPGP digital signature
Re: r279278 failed to build (yacc: maximum table size exceeded)
On Sat, Feb 28, 2015 at 12:18:33AM +0400, Arseny Nasokin wrote:
On 25 February 2015 at 23:15, Jung-uk Kim j...@freebsd.org wrote:
I have FreeBSD 11.0-CURRENT r265265 with OSRELDATE 1100020 and
invalid YACC. So This conditional expression must be fixed to check
if this 11.x and yacc is not changed.
Wow, that's more than 9-month old now.
In my hypothetical patch I set OSRELDATE to invalid abstract
future version, because it's only concept and I have no time to fix
it correctly now.
If you insist, you can try this:
- --- Makefile.inc1
+++ Makefile.inc1
@@ -1274,7 +1274,8 @@
_awk= usr.bin/awk
.endif
- -.if ${BOOTSTRAPPING} 1001506
+.if ${BOOTSTRAPPING} 1001506 || \
+(${BOOTSTRAPPING} = 110 ${BOOTSTRAPPING} 1100046)
_yacc= lib/liby \
usr.bin/yacc
(but I won't commit it.)
Should I fill PR for?
Yes, please do.
Glen
pgpCRFfFeKgEM.pgp
Description: PGP signature
Re: r279278 failed to build (yacc: maximum table size exceeded)
On 27 February 2015 at 23:21, Glen Barber g...@freebsd.org wrote:
On Sat, Feb 28, 2015 at 12:18:33AM +0400, Arseny Nasokin wrote:
On 25 February 2015 at 23:15, Jung-uk Kim j...@freebsd.org wrote:
I have FreeBSD 11.0-CURRENT r265265 with OSRELDATE 1100020 and
invalid YACC. So This conditional expression must be fixed to check
if this 11.x and yacc is not changed.
Wow, that's more than 9-month old now.
In my hypothetical patch I set OSRELDATE to invalid abstract
future version, because it's only concept and I have no time to fix
it correctly now.
If you insist, you can try this:
- --- Makefile.inc1
+++ Makefile.inc1
@@ -1274,7 +1274,8 @@
_awk= usr.bin/awk
.endif
- -.if ${BOOTSTRAPPING} 1001506
+.if ${BOOTSTRAPPING} 1001506 || \
+(${BOOTSTRAPPING} = 110 ${BOOTSTRAPPING} 1100046)
_yacc= lib/liby \
usr.bin/yacc
(but I won't commit it.)
Should I fill PR for?
Yes, please do.
Glen
Hi,
I've filled PR 198081
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198081
-- Eir Nym
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r279278 failed to build (yacc: maximum table size exceeded)
On 25 February 2015 at 23:15, Jung-uk Kim j...@freebsd.org wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 02/25/2015 14:59, Arseny Nasokin wrote:
On 25 February 2015 at 22:14, Jung-uk Kim j...@freebsd.org
mailto:j...@freebsd.org wrote:
On 02/25/2015 14:05, Glen Barber wrote:
On Wed, Feb 25, 2015 at 10:51:31PM +0400, Arseny Nasokin wrote:
On 25 February 2015 at 20:27, Jung-uk Kim j...@freebsd.org
mailto:j...@freebsd.org
wrote:
Your installed yacc(1) is too old, i.e., your world was
built from head before r274460. FYI, this commit fixes the
above problem for building from stable:
https://svnweb.freebsd.org/changeset/base/278975
For building from old head (pre-r274460), you have to
manually bootstrap yacc first, e.g., something like this:
cd /usr/src/usr.bin/yacc make clean cleandepend make all
make install make clean cleandepend cd /usr/src make
buildworld
Hi, guys,
I've found the fix by forcing to add yacc(1) to bootstrap
build.
Makefile.inc1, line 1277:
if ${BOOTSTRAPPING} 1001506 _yacc= lib/liby \
change to:
if ${BOOTSTRAPPING} 1201506 ## It is for test purposes
only!!! _yacc= lib/liby \
This can be set to 1001507 now; __FreeBSD_version was bumped
earlier today.
Nope, 1001506 is correct, i.e., the change was MFC'ed to stable/10
and __FreeBSD_version was bumped to reflect it.
https://svnweb.freebsd.org/changeset/base/277087
Jung-uk Kim
Jung,
I have FreeBSD 11.0-CURRENT r265265 with OSRELDATE 1100020 and
invalid YACC. So This conditional expression must be fixed to check
if this 11.x and yacc is not changed.
Wow, that's more than 9-month old now.
In my hypothetical patch I set OSRELDATE to invalid abstract
future version, because it's only concept and I have no time to fix
it correctly now.
If you insist, you can try this:
- --- Makefile.inc1
+++ Makefile.inc1
@@ -1274,7 +1274,8 @@
_awk= usr.bin/awk
.endif
- -.if ${BOOTSTRAPPING} 1001506
+.if ${BOOTSTRAPPING} 1001506 || \
+(${BOOTSTRAPPING} = 110 ${BOOTSTRAPPING} 1100046)
_yacc= lib/liby \
usr.bin/yacc
(but I won't commit it.)
Jung-uk Kim
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iQEcBAEBCAAGBQJU7i1kAAoJEHyflib82/FGh9kH/07QOQ+xlPQVApJD+x1u/c4b
G1g4mmOhEKKOjVK9dJFKY1hvTiLYkOB3UDwJH8rmzbglInY+eepbD9Ac15Dtl90b
RFvNEB3B7Rwzt9ljg2zH/OQ6HnPCHgreF31ggkmKLszQ/Rrv62KTmN9ML4dkx897
7jAPwwtMb2XfLzyAc2fMNne3xl/zmdzafcqA+87UOUJ3Jb4rv35/x3kSrOqsMzvj
A3ufAepzG2J0+fH62ZP2L/FfuXoaKP0hlIpXZwNYAciSf+GAa7McYyu1aaRZQedF
1DSphDtSFnJKR+ltIvDL5WH98Zi0iOu5FHb9bLfW/s+bV+oxs4/ZQHtxsIejLN4=
=3xA9
-END PGP SIGNATURE-
Should I fill PR for?
-- Eir Nym
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Jenkins build became unstable: FreeBSD_HEAD-tests2 #780
See https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests2/780/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
ggatec: ioctl(/dev/ggctl): Invalid argument
Hi, I am trying to use ggatec to mount a device from another host running the same FreeBSD version (8.1) and I am seeing the following error: freebsd-2% ggatec create -vo rw hostname /dev/xbd7 info: Connected to the server: hostname:3080. debug: Sending version packet. debug: Sending initial packet. debug: Receiving initial packet. debug: Received initial packet. info: Connected to the server: hostname:3080. debug: Sending version packet. debug: Sending initial packet. debug: Receiving initial packet. debug: Received initial packet. error: ggatec: ioctl(/dev/ggctl): Invalid argument. error: Exiting. If I use ggatec to mount the device from the same host (i.e. ggated and ggatec on same host), than it works, but for remote host it doesn't. Any ideas? Regards,Bhaskar ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: sa(4) driver changes available for test
On Fri, Feb 27, 2015 at 20:05:05 +0100, Harald Schmalzbauer wrote: Bez?glich Kenneth D. Merry's Nachricht vom 26.02.2015 23:42 (localtime): ? And (untested) patches against FreeBSD stable/10 as of SVN revision 278974: http://people.freebsd.org/~ken/sa_changes.stable_10.20150218.1.txt ? I'm glad it is working well for you! You can do larger I/O sizes with the Adaptec by changing your MAXPHYS and DFLTPHYS values in your kernel config file. e.g.: options MAXPHYS=(1024*1024) options DFLTPHYS=(1024*1024) If you set those values larger, you won't be able to do more than 132K with the sym(4) driver on an x86 box. (It limits the maximum I/O size to 33 segments * PAGE_SIZE.) Thanks for the hint! I wasn't aware that kern.cam.sa.N.maxio has driver limitations corresponding to systems MAX/DFLTPHYS. I thought only silicon limitations define it's value. It depends on the driver. I thought that the Adaptec drivers go off of MAXPHYS (because that's what the driver author told me last week :), but in looking at the code, they actually have a hard-coded value that can be increased. You can bump AHC_MAXPHYS or AHD_MAXPHYS in aic7xxx_osm.h or aic79xx_osm.h, respectively. In order to make any difference, though, you would have to bump MAXPHYS/DFLTPHYS (so the sa(4) driver will use that value) or change the ahc(4)/ahd(4) driver to set the maxio field in the path inquiry CCB. But in order to have a best matching pre-production test-environment, I nevertheless replaced it, now using mpt(4) instead of ahc(4)/ahc_pci on PCI-X@S3210 (for parallel tape drives I consistently have mpt(4)@PCIe, which is the same LSI(53c1020) chip but with on-board PCI-X-PCIe bridge). Okay. That should work. Still just works fine ! :-) (stable_10.20150218.1-patchset with LTO2, LTO3 and DDS5) With DDS5, densitiy is reported as unknown. If I remember correctly, you have your DDS4 reporting DDS4? That means that we need to add DDS5 to the density table in libmt. Can you send the output of 'mt status -v'? It would actually be helpful for all three drives. Also, do any of your drives give a full report for 'mt getdensity'? If so, can you send that as well? (By full report, I mean more than one line.) We don't have density codes for DDS-5/DAT 72, DAT 160 or DAT 320 yet. It looks like DDS-5 should be 0x47. therefore I'd like to point to the new port misc/vdmfec https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197950 That looks cool. :) I'm not a ports committer, but hopefully one of them will pick it up. Cool it is indeed, but whether it's really usefull or not is beyond my expertise. I couldn't collect much MT experience yet. I know that LTO and similar modern MT technology do their own ECC (in the meaning of erasure code, mostly Reed-Solomon). What I don't know (but wanting to be best prepared for) is how arbitrary LTO drives behave, if the one (1) in 10^17 bits was detected to be uncorrectable. If it wasn't detected, the post erasure code (vdmfec in that case) would help for sure. But If the drive just cuts the output, or stops streaming at all, vdmfec was useless? There is a difference in the uncorrectable bit error rate and the undetectable bit error rate. The uncorrectable bit error rate for LTO-6 is 1 in 10^17. It is 1 in 10^19 for Oracle T1 C/D drives, and 1 in 10^20 for IBM TS1150. Seagate Enterprise drives claim to have an uncorrectable bit error rate of 1 sector per 10^15 bits read. See: http://www.oracle.com/us/products/servers-storage/storage/tape-storage/t1c-reliability-wp-409919.pdf http://www.spectralogic.com/index.cfm?fuseaction=home.displayFileDocID=2513 http://www.seagate.com/www-content/product-content/enterprise-hdd-fam/enterprise-capacity-3-5-hdd/constellation-es-4/en-us/docs/enterprise-capacity-3-5-hdd-ds1791-8-1410us.pdf The second white paper claims that tape has an undetectable bit error rate of 1 in 1.6x10^33 bits. I assume it is referring to TS1150, but I don't know for sure. It is far more likely that your tape or tape drive will break than it is that you would get a bad bit back from the drive. According to excerpts of Study of Perpendicular AME Media in a Linear Tape Drive, LTO-4 has a soft read error rate of 1 in 10^6 bits and DDS has 1 in 10^4 bits (!!!, according to HP C1537A DDS 3 - ACT/Apricot). So with DDS, _every_ single block pax(1) writes to tape needs to be internally corrected! Of course, nobody wants zfs' send output stream to DDS, it's much too slow/small, but just to mention. For archives of zfs streams, I don't feel safe relying on the tape drives' FEC, which was designed for backup solutions which do their own blocking+cheksumming, so the very seldom to expect uncorrectable read error would at worst lead to some/single unrecoverable files ? even in case of database files most likely post-recoverable. But with one flipped bit in the zfs stream, you'd loose hundred of
Re: sa(4) driver changes available for test
On Feb 17, 2015, at 1:36 PM, Kenneth D. Merry k...@freebsd.org wrote: On Sat, Feb 14, 2015 at 18:22:43 -0500, Dan Langille wrote: On Feb 13, 2015, at 7:32 PM, Kenneth D. Merry k...@freebsd.org wrote: I have a fairly large set of changes to the sa(4) driver and mt(1) driver that I'm planning to commit in the near future. A description of the changes is here and below in this message. If you have tape hardware and the inclination, I'd appreciate testing and feedback. I have a DLT 8000 and an SDLT 220. I don't have anything running current, but I have a spare machine which I could use for testing. Do you see any value is tests with that hardware? I'd be testing it via Bacula. disclosure: I'm the sysutils/bacula-* maintainer and a Bacula committer. Actually, yes. Bacula is a bit tricky to configure, so your trying it out would be helpful if you have the time. I have been unable to test yet. I've encountered time and hardware issues. I may be able to try tomorrow. In looking at the manuals for both the SDLT 220 and the DLT 8000, they both claim to support long position information for the SCSI READ POSITION command. You can see what I'm talking about by doing: mt eod mt status On my DDS-4 tape drive, this shows: # mt -f /dev/nsa3 status Drive: sa3: SEAGATE DAT06240-XXX 8071 Serial Number: HJ00YWY - Mode Density Blocksize bpi Compression Current: 0x26:DDS-4 1024 bytes 97000enabled (DCLZ) - Current Driver State: at rest. - Partition: 0 Calc File Number: -1 Calc Record Number: -1 Residual:0 Reported File Number: -1 Reported Record Number: -1 Flags: None But on an LTO-5, which will give long position information, I get: [root@doc ~]# mt status Drive: sa0: IBM ULTRIUM-HH5 E4J1 - Mode Density Blocksize bpi Compression Current: 0x58:LTO-5 variable 384607 enabled (0x1) - Current Driver State: at rest. - Partition: 0 Calc File Number: 2 Calc Record Number: -1 Residual:0 Reported File Number: 2 Reported Record Number: 32373 Flags: None That, in combination with the changes I made to the position information code in the driver, mean that even the old MTIOCGET ioctl should return an accurate file number at end of data. e.g., on the LTO-5: [root@doc ~]# mt ostatus Mode Density Blocksize bpi Compression Current: 0x58:LTO-5 variable 384607 0x1 -available modes- 0:0x58:LTO-5 variable 384607 0x1 1:0x58:LTO-5 variable 384607 0x1 2:0x58:LTO-5 variable 384607 0x1 3:0x58:LTO-5 variable 384607 0x1 - Current Driver State: at rest. - File Number: 2 Record Number: -1 Residual Count -1 So the thing to try, in addition to just making sure that Bacula continues to work properly, is to try setting this for the tape drive in bacula-sd.conf: Hardware End of Medium = yes It looks like the Bacula tape program (btape) has a test mode, and it would be good to run through the tests on one of the tape drives and see whether they work, and whether the results are different before and after the changes. I'm not sure how to enable the test mode. I'll let the other Bacula devs know about this. They deal with the hardware. I work on PostgreSQL. Thanks! If there are additional features they would like out of the tape driver, I'm happy to talk about it. (Or help if they'd like to use the new status reporting ioctl, MTIOCEXTGET or any of the other new ioctls.) Ken -- Kenneth Merry k...@freebsd.org — Dan Langille http://langille.org/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r279278 failed to build (yacc: maximum table size exceeded)
On Wed, Feb 25, 2015 at 12:11:29PM -0800, Garrett Cooper wrote: I was going to propose something a bit more radical — I can remove the BOOTSTRAPPING conditionals and simplify the code on 10-STABLE / 11-CURRENT. Maintaining BOOTSTRAPPING is error prone and it’s not saving much time in the long run in builds (it's taking longer to diagnose issues, test them, and commit fixes which will break at a later date). I’ve been bitten by this once because I don’t run ancient CURRENT/STABLE (r279198) and here are a couple follow up commits bumping tools versions in the past (e.g. r278975, r269662, etc). Just a thought. This may be appropriate for contributed code that will build on older FreeBSD versions without issues, but I don't like being forced to add (mostly untested) compatibility code with usage of recent libc features. For example, utilities like cp and touch currently use utimensat/futimens without #ifdef mess or extra code in libegacy. The strict BOOTSTRAPPING conditionals allow removing bootstrap tools eventually, when building from such old versions as to need them is no longer supported. -- Jilles Tjoelker ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Jenkins build is still unstable: FreeBSD_HEAD-tests2 #781
See https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests2/781/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Current build world failed: bsdxml is missing?
On 17 February 2015 at 01:10, Arseny Nasokin eir...@gmail.com wrote: On 16 February 2015 at 17:04, Arseny Nasokin eir...@gmail.com wrote: On 16 February 2015 at 15:34, Garrett Cooper yaneurab...@gmail.com wrote: On Feb 16, 2015, at 4:28, Arseny Nasokin eir...@gmail.com wrote: Geom XML output is failed to build. Build box SVN version is: CURRENT-r265265. Related log output is: --- sbin.all__D --- /usr/obj/usr/src/tmp/usr/lib/libgeom.a(geom_xml2tree.o): In function `geom_xml2tree': /usr/src/lib/libgeom/geom_xml2tree.c:(.text+0x5e): undefined reference to `XML_ParserCreate' /usr/src/lib/libgeom/geom_xml2tree.c:(.text+0xa2): undefined reference to `XML_SetUserData' /usr/src/lib/libgeom/geom_xml2tree.c:(.text+0xb4): undefined reference to `XML_SetElementHandler' /usr/src/lib/libgeom/geom_xml2tree.c:(.text+0xc1): undefined reference to `XML_SetCharacterDataHandler' /usr/src/lib/libgeom/geom_xml2tree.c:(.text+0xdb): undefined reference to `XML_Parse' /usr/src/lib/libgeom/geom_xml2tree.c:(.text+0xfd): undefined reference to `XML_ParserFree' /usr/src/lib/libgeom/geom_xml2tree.c:(.text+0x373): undefined reference to `XML_ParserFree' /usr/src/lib/libgeom/geom_xml2tree.c:(.text+0x37d): undefined reference to `XML_GetErrorCode' /usr/src/lib/libgeom/geom_xml2tree.c:(.text+0x397): undefined reference to `XML_ParserFree' /usr/obj/usr/src/tmp/usr/lib/libgeom.a(geom_xml2tree.o): In function `StartElement': /usr/src/lib/libgeom/geom_xml2tree.c:(.text+0x3eb): undefined reference to `sbuf_new' /usr/src/lib/libgeom/geom_xml2tree.c:(.text+0x735): undefined reference to `XML_StopParser' /usr/obj/usr/src/tmp/usr/lib/libgeom.a(geom_xml2tree.o): In function `EndElement': /usr/src/lib/libgeom/geom_xml2tree.c:(.text+0x7bb): undefined reference to `sbuf_finish' /usr/src/lib/libgeom/geom_xml2tree.c:(.text+0x7d0): undefined reference to `sbuf_data' /usr/src/lib/libgeom/geom_xml2tree.c:(.text+0x7e9): undefined reference to `sbuf_delete' /usr/src/lib/libgeom/geom_xml2tree.c:(.text+0xa25): undefined reference to `XML_StopParser' /usr/obj/usr/src/tmp/usr/lib/libgeom.a(geom_xml2tree.o): In function `CharData': /usr/src/lib/libgeom/geom_xml2tree.c:(.text+0xc62): undefined reference to `sbuf_bcat’ I think the fact that it’s missing sbuf* is the underlying cause for the failures seen here. Can you please post more context in a pastebin or something (what phase did buildworld fail, what options did you pass to make, i.e. -DNO_CLEAN, etc?)? Thanks! Thank you for fast reply, I remove /usr/obj/usr and $TMPDIR explicitly with rm(1) and chflags(1) and only then build world. (I use separate $TMPDIR for that process) # make toolchain 'SRCCONF=/path/to/src.conf' -DNO_CLEAN '__MAKE_CONF=/dev/null' 'TARGET=amd64' # make buildworld 'SRCCONF=/path/to/src.conf' -DNO_CLEAN '__MAKE_CONF=/dev/null' 'TARGET=amd64' ... The stage is: 4.4 (building everything) Build script is here: https://bitbucket.org/eirnym/bsd/src/9822ba9b1ed54414a79d5a632b3857f8b671c769/builder/mkw.sh?at=default -- Eir Nym Full log is here http://eroese.org/_/_/pub/bsd/world.amd64.278844.log (~23 Mb) Recent part is: gzip -cn /usr/src/sbin/atm/atmconfig/atmconfig.8 atmconfig.8.gz === sbin/badsect (all) cc -O2 -pipe -DNDEBUG -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Qunused-arguments -c /usr/src/sbin/badsect/badsect.c ctfconvert -L VERSION badsect.o ERROR: ctfconvert: badsect.o doesn't have type data to convert cc -O2 -pipe -DNDEBUG -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Qunused-arguments -static -o badsect badsect.o -lufs ctfmerge -L VERSION -o badsect badsect.o ERROR: ctfmerge: No ctf sections found to merge gzip -cn /usr/src/sbin/badsect/badsect.8 badsect.8.gz === sbin/bsdlabel (all) cc -O2 -pipe -DNDEBUG -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments -c /usr/src/sbin/bsdlabel/bsdlabel.c
