Re: gbde destroy doesn't match man page?
In message 2945485.zemf81r...@ralph.baldwin.cx, John Baldwin writes: On Saturday, August 23, 2014 10:16:42 AM Poul-Henning Kamp wrote: In message 20140820215522.ga92...@bewilderbeast.blackhelicopters.org, Michae l W. Lucas writes: Playing with GBDE for my FreeBSD disk book, on: # uname -a FreeBSD storm 11.0-CURRENT FreeBSD 11.0-CURRENT #6 r269010: Wed Jul 23 11:13:17 EDT 2014 mwlucas@storm:/usr/obj/usr/src/sys/GENERIC amd64 According to the man page, I should be able to destroy all copies of the key with gbde destroy device -n -1. It's in the examples. When I try it I get: I think that is an oversight in the code. Can you expand on this? I.e. what should the code do if it is fixed? Hmm, now that I think about it, -n doesn't make sense because any one of the four keys can open the volume as needed to blow away the masterkey. The manual page should just be fixed. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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: How to get a mouse in vt(4) -- NEWCONS
On Mon, Aug 25, 2014 at 5:54 PM, Chris H bsd-li...@bsdforge.com wrote: On Mon, 25 Aug 2014, Chris H wrote: I also read that hw.vga.textmode is available. However sysctl hw.vga.textmode returns unknown oid. It is a boot-time-only setting for loader.conf. hw.vga.textmode=1 boots in text mode. Ahh, I see. Thank you very much, Warren, for the reply. :) --Chris But the mouse should work fine with vt(4). It does for me. You do need to run moused, though that was the case with cs(4), as well. D'OH! Sorry my bad. I overlooked the entry in loader.conf(5) on my other box. Sorry for the noise. The lack of blink support was just noted in the last post to this list, so we can hope to hear a bit about the status of blink soon. That would be good to know. Thank you for taking the time to respond, Kevin. --Chris -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkober...@gmail.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 ___ 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: KQueue 0-length UDP packet
Hi, What I wanted to ask is: why does FreeBSD kqueue implementation treat `SO_RCVLOWAT` as a raw packet size watermark, and not using the actual data size for filtering out events? It looks like SO_RCVLOWAT refers to the number of bytes in the socket buffer, not raw packet bytes. In the case of an arriving UDP packet there is always a 'struct sockaddr' in the buffer that contains the source address/port of the message. For IPv4 this is 16 bytes and for IPv6 28 bytes. I think this is intended behavior, as this is data you can read with recvfrom or recvmsg. POSIX says Receive calls may still return less than the low water mark if an error occurs, a signal is caught, or the type of data next in the receive queue is different from that returned (for example, out-of-band data). So in this case this data is address data. On the other hand, NOTE_LOWAT from kevent refers to data/protocol bytes. The semantics were changed in 2002: http://marc.info/?l=freebsd-archm=103587526507822w=2 The value you get in 'data' also refers to the number of protocol data bytes available. I've had a look at how OpenBSD handles this. It returns the number of protocol data bytes with ioctl(s, FIONREAD, len) but the number of bytes in the socket buffer in the 'data' member of kevent, so exactly the other way around compared to FreeBSD. SO_RCVLOWAT works still the same, though. Cheers, Jan ___ 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 10 and zfsd
Any hope of zfsd before the freeze for 10.1-RELEASE? Thanks! ___ 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: ktrace -c behavior
On 08/25/2014 16:23, John Baldwin wrote: On Monday, August 25, 2014 09:21:48 AM Eric van Gyzen wrote: On 08/24/2014 19:53, John-Mark Gurney wrote: Eric van Gyzen wrote this message on Fri, Aug 22, 2014 at 15:26 -0400: On 08/22/2014 15:20, John-Mark Gurney wrote: Eric van Gyzen wrote this message on Fri, Aug 22, 2014 at 15:16 -0400: What behavior would you expect from this sequence of commands? ktrace -tw -p 1234 ktrace -c -p 1234 Based on this... -c Clear the trace points associated with the specified file or processes. and/or just add specified: Clear the specified trace points ... But what if I didn't specify them? You specified the default by not specificly specifing any different ones.. :) Confused? :) Amused. :) Adding specified is the first thing that came to my mind as well. or maybe selected? Perhaps, but I didn't select them, either. My original suggestion is more--dare I use this word again--specific. It explains exactly how the command behaves. But then do we need to annotate every place that uses trace points to add this language? Note that the 'command' description uses the language John- mark suggested: command Execute command with the specified trace flags. My vote would be to add specified to the description of -c, but to improve the the description of -t itself from: -t trstr The string argument represents the kernel trace points, one per letter. The following table equates the letters with the trace- points: to: -t trstr Specify the list of trace points to enable or disable, one per letter. If an explicit list is not specified, the default set of trace points is used. The following trace points are supported: Okay, that would work. Minor note: You might avoid repeating specified in the -c description: Clear the specified trace points associated with the /given/ file or processes. Thanks, guys. Eric ___ 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: [PATCH] Packet loss when 'control' messages are present with large data (sendmsg(2))
On Mon, Aug 25, 2014 at 1:52 PM, John Baldwin j...@freebsd.org wrote: On Friday, August 22, 2014 01:34:28 PM Harald Schmalzbauer wrote: Bezüglich Yuri's Nachricht vom 02.09.2013 06:54 (localtime): Please check in this patch: http://www.freebsd.org/cgi/query-pr.cgi?pr=181741 Please MFC into 9.X Description of the problem is within PR. Thanks, Yuri Hello, I guess this fix should make it into 10.1. Can someone check please? A fix has to make into HEAD first. I've cc'd Alan who responded to the bug. Alan, note that glebius@ already committed the test case to HEAD a while ago. First, Gleb's testcase needs to be converted to ATF. This would be a good exercise for anybody who's new to ATF and wants some practice. Anybody interested? -- John Baldwin ___ 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 10 and zfsd
Status update below: The projects/zfsd project branch is up to date. Merging it to CURRENT is blocked on these tasks. 1) (The biggie) We must resolve the issue with multiple geom opens. Geom tries to prevent any two consumers from simultaneously opening the same provider. This is why, for example, you can't do dd if=/dev/zero of=/dev/ada0 if your ada0 has a mounted file system. However, ZFS internally opens spare devices multiple times. The only way that geom will allow that is if ZFS opens devices non-exclusively. That means that you will lose your protection. Fixing this correctly requires deep changes to ZFS to remove the multiple opens. 2) Need to merge in zfsd's functional tests. I'm currently working on this issue as time allows. Merged into the projects/zfsd/head branch by change 270604. Merging to head is blocked by three issues: a) The atf-ksh93 hack. The correct solution is to modify all the test programs (not the test cases) so they can run under /bin/sh. That will take some effort. b) Some test cases reference Spectra Logic internal bug numbers. We need to file FreeBSD PRs for all of them and change the references. c) It uses some ATF config variables that are not yet documented in tests(7). 3) It needs a manpage. 4) Various bug fixes need to be merged to the kernel and to LibZFS. Coordinating with Illumos makes that process slow. will@ is working on it as time allows. gibbs@ has been making progress here, with mahrens@ providing code review. But it is still slow. 5) libdevctl needs to be made private 6) The sequential packet feature added to devd in the zfsd project branch at revision r266519 must be merged to head. It's currently waiting for review from imp@ and ian@. Merged by r270004. To answer Mark's question: no, we can't finish all of this in time for 10.1. Sorry. -Alan ___ 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
did tar(1) loose xz compression support in 11?
Greetings, I'm currently testing 11. My build / install is from about 2 days ago. I generally use xz compression, when creating archives. But when I attempt the following: tar -cvJ --options xz:9 -f ./archive-name.tar.xz ./file it returns the following: tar: Undefined option: `xz:9' This has always worked in previous versions. Has the syntax changed, and the man(1) pages just haven't caught up? Thank you for all your time, and consideration. --Chris ___ 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: did tar(1) loose xz compression support in 11?
On 8/26/14 11:05 AM, Chris H wrote: Greetings, I'm currently testing 11. My build / install is from about 2 days ago. I generally use xz compression, when creating archives. But when I attempt the following: tar -cvJ --options xz:9 -f ./archive-name.tar.xz ./file it returns the following: tar: Undefined option: `xz:9' This has always worked in previous versions. Has the syntax changed, and the man(1) pages just haven't caught up? I use: tar -cJ --options xz:compression-level=1 .. on head. Are you using the right syntax? -- Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV signature.asc Description: OpenPGP digital signature
Re: did tar(1) loose xz compression support in 11?
On 8/26/14 11:05 AM, Chris H wrote: Greetings, I'm currently testing 11. My build / install is from about 2 days ago. I generally use xz compression, when creating archives. But when I attempt the following: tar -cvJ --options xz:9 -f ./archive-name.tar.xz ./file it returns the following: tar: Undefined option: `xz:9' This has always worked in previous versions. Has the syntax changed, and the man(1) pages just haven't caught up? I use: tar -cJ --options xz:compression-level=1 .. on head. Are you using the right syntax? Apparently not. Using your example works as expected. RELENG_8, and RELENG_9 use short-hand; tar -cvJ --options xz:9 Why/when the change to long-hand? Seems a shame. Now I get to modify all my scripts, and such. :P Altho I don't suppose it'd be a big deal to back out (revert) the changes made to tar(1). :) Thank you, very much, Peter. For taking the time to respond. --Chris -- Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV ___ 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: [PATCH] Packet loss when 'control' messages are present with large data (sendmsg(2))
On Tuesday, August 26, 2014 11:05:12 am Alan Somers wrote: On Mon, Aug 25, 2014 at 1:52 PM, John Baldwin j...@freebsd.org wrote: On Friday, August 22, 2014 01:34:28 PM Harald Schmalzbauer wrote: Bezüglich Yuri's Nachricht vom 02.09.2013 06:54 (localtime): Please check in this patch: http://www.freebsd.org/cgi/query-pr.cgi?pr=181741 Please MFC into 9.X Description of the problem is within PR. Thanks, Yuri Hello, I guess this fix should make it into 10.1. Can someone check please? A fix has to make into HEAD first. I've cc'd Alan who responded to the bug. Alan, note that glebius@ already committed the test case to HEAD a while ago. First, Gleb's testcase needs to be converted to ATF. This would be a good exercise for anybody who's new to ATF and wants some practice. Anybody interested? While that would be nice, I don't know that it's quite fair to require the test to be converted before working on a possible fix. The existing test doesn't seem that hard to run by hand: % cd work/freebsd/head/tools/regression/sockets/unix_passfd/ % make ... % ./unix_passfd beginning test1-simplesendfd test1-simplesendfd passed ... beginning test8-rigths+creds+payload unix_passfd: test8-rigths+creds+payload: recvmsg: 24 bytes received I only say this because in the bug followup you seemed to have described a possible solution so it seems that you would be able to develop a fix quicker than other folks since you are already familiar with the issues involved. (Also, you've fixed other related issues recently.) -- John Baldwin ___ 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 10 and zfsd
August 26 2014 10:21 AM, Alan Somers asom...@freebsd.org wrote: Merged into the projects/zfsd/head branch by change 270604. Merging to head is blocked by three issues: a) The atf-ksh93 hack. The correct solution is to modify all the test programs (not the test cases) so they can run under /bin/sh. That will take some effort. Can you provide a link to the atf-ksh93 code? ___ 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 10 and zfsd
On Tue, Aug 26, 2014 at 1:39 PM, Mark Felder f...@freebsd.org wrote: August 26 2014 10:21 AM, Alan Somers asom...@freebsd.org wrote: Merged into the projects/zfsd/head branch by change 270604. Merging to head is blocked by three issues: a) The atf-ksh93 hack. The correct solution is to modify all the test programs (not the test cases) so they can run under /bin/sh. That will take some effort. Can you provide a link to the atf-ksh93 code? There's not much to it. It simply sets an environment variable and calls atf-sh. What's more interesting is libtest.kshlib. In order to eliminate atf-ksh93, we would need to modify libtest.kshlib to run under /bin/sh. Alternatively, it may be easier to split libtest.kshlib into two files: a small /bin/sh-compatible that can be sourced by the ATF test programs, and a ksh93 script that only needs to be sourced by the ATF test cases. https://svnweb.freebsd.org/base/projects/zfsd/head/libexec/atf/atf-ksh93/ https://svnweb.freebsd.org/base/projects/zfsd/head/tests/sys/cddl/zfs/include/libtest.kshlib ___ 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 10 and zfsd
On Aug 26, 2014, at 12:45, Alan Somers asom...@freebsd.org wrote: On Tue, Aug 26, 2014 at 1:39 PM, Mark Felder f...@freebsd.org wrote: August 26 2014 10:21 AM, Alan Somers asom...@freebsd.org wrote: Merged into the projects/zfsd/head branch by change 270604. Merging to head is blocked by three issues: a) The atf-ksh93 hack. The correct solution is to modify all the test programs (not the test cases) so they can run under /bin/sh. That will take some effort. Can you provide a link to the atf-ksh93 code? There's not much to it. It simply sets an environment variable and calls atf-sh. What's more interesting is libtest.kshlib. In order to eliminate atf-ksh93, we would need to modify libtest.kshlib to run under /bin/sh. Alternatively, it may be easier to split libtest.kshlib into two files: a small /bin/sh-compatible that can be sourced by the ATF test programs, and a ksh93 script that only needs to be sourced by the ATF test cases. I'm working on integrating the dtrace testcases into kyua, then atf under Kyua as time permits, but I'm not rewriting the core test code (yet), because I want to reduce divergence with upstream. Why not just require ksh93 from ports? Cheers! -Garrett ___ 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: [PATCH] Packet loss when 'control' messages are present with large data (sendmsg(2))
On Tue, Aug 26, 2014 at 03:15:31PM -0400, John Baldwin wrote: On Tuesday, August 26, 2014 11:05:12 am Alan Somers wrote: On Mon, Aug 25, 2014 at 1:52 PM, John Baldwin j...@freebsd.org wrote: On Friday, August 22, 2014 01:34:28 PM Harald Schmalzbauer wrote: Bezüglich Yuri's Nachricht vom 02.09.2013 06:54 (localtime): Please check in this patch: http://www.freebsd.org/cgi/query-pr.cgi?pr=181741 Please MFC into 9.X Description of the problem is within PR. Thanks, Yuri Hello, I guess this fix should make it into 10.1. Can someone check please? A fix has to make into HEAD first. I've cc'd Alan who responded to the bug. Alan, note that glebius@ already committed the test case to HEAD a while ago. First, Gleb's testcase needs to be converted to ATF. This would be a good exercise for anybody who's new to ATF and wants some practice. Anybody interested? While that would be nice, I don't know that it's quite fair to require the test to be converted before working on a possible fix. The existing test doesn't seem that hard to run by hand: % cd work/freebsd/head/tools/regression/sockets/unix_passfd/ % make ... % ./unix_passfd beginning test1-simplesendfd test1-simplesendfd passed ... beginning test8-rigths+creds+payload unix_passfd: test8-rigths+creds+payload: recvmsg: 24 bytes received I only say this because in the bug followup you seemed to have described a possible solution so it seems that you would be able to develop a fix quicker than other folks since you are already familiar with the issues involved. (Also, you've fixed other related issues recently.) As it happens, I went ahead and did this anyway: https://reviews.freebsd.org/D689 ___ 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 10 and zfsd
August 26 2014 2:45 PM, Alan Somers asom...@freebsd.org wrote: On Tue, Aug 26, 2014 at 1:39 PM, Mark Felder f...@freebsd.org wrote: August 26 2014 10:21 AM, Alan Somers asom...@freebsd.org wrote: Merged into the projects/zfsd/head branch by change 270604. Merging to head is blocked by three issues: a) The atf-ksh93 hack. The correct solution is to modify all the test programs (not the test cases) so they can run under /bin/sh. That will take some effort. Can you provide a link to the atf-ksh93 code? There's not much to it. It simply sets an environment variable and calls atf-sh. What's more interesting is libtest.kshlib. In order to eliminate atf-ksh93, we would need to modify libtest.kshlib to run under /bin/sh. Alternatively, it may be easier to split libtest.kshlib into two files: a small /bin/sh-compatible that can be sourced by the ATF test programs, and a ksh93 script that only needs to be sourced by the ATF test cases. https://svnweb.freebsd.org/base/projects/zfsd/head/libexec/atf/atf-ksh93/ https://svnweb.freebsd.org/base/projects/zfsd/head/tests/sys/cddl/zfs/include/libtest.kshlib Depending on how complicated it is we might be able to coerce dteske into checking it out. He could write an sh mastery book... I'm sure he could assist with this. :-) ___ 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 10 and zfsd
August 26 2014 2:49 PM, Garrett Cooper yaneurab...@gmail.com wrote: Why not just require ksh93 from ports? Because zfsd is going to be in base, not in ports. Everything in base needs to work without any ports requirements. Also ksh93 has been... problematic. It has a history of breaking on i386, sparc64, current, etc. It's not exactly a reliable dependency. ___ 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: did tar(1) loose xz compression support in 11?
Chris H bsd-li...@bsdforge.com writes: On 8/26/14 11:05 AM, Chris H wrote: Greetings, I'm currently testing 11. My build / install is from about 2 days ago. I generally use xz compression, when creating archives. But when I attempt the following: tar -cvJ --options xz:9 -f ./archive-name.tar.xz ./file it returns the following: tar: Undefined option: `xz:9' This has always worked in previous versions. Has the syntax changed, and the man(1) pages just haven't caught up? I use: tar -cJ --options xz:compression-level=1 .. on head. Are you using the right syntax? Apparently not. Using your example works as expected. RELENG_8, and RELENG_9 use short-hand; tar -cvJ --options xz:9 Why/when the change to long-hand? Seems a shame. Now I get to modify all my scripts, and such. :P Altho I don't suppose it'd be a big deal to back out (revert) the changes made to tar(1). :) I can't find any changes that would make the syntax change. At least, not in quite a long while. Therefore, this change may not be intentional. However, I looked at the the manual page from 9.3, and its description of the features looks the same as on the latest HEAD, and *doesn't* look like leaving out a key (in this case, compression-level) is ever compliant. You might try the latest (or older) libarchive from the ports, and compare its behaviour. Also, there are a number (amusingly many, in fact) of other ways of specifying these parameters that may be more convenient for you, so another look throught the tar(1) manual might save you a few minutes. Good luck. ___ 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 10 and zfsd
On Tue, Aug 26, 2014 at 1:48 PM, Garrett Cooper yaneurab...@gmail.com wrote: On Aug 26, 2014, at 12:45, Alan Somers asom...@freebsd.org wrote: On Tue, Aug 26, 2014 at 1:39 PM, Mark Felder f...@freebsd.org wrote: August 26 2014 10:21 AM, Alan Somers asom...@freebsd.org wrote: Merged into the projects/zfsd/head branch by change 270604. Merging to head is blocked by three issues: a) The atf-ksh93 hack. The correct solution is to modify all the test programs (not the test cases) so they can run under /bin/sh. That will take some effort. Can you provide a link to the atf-ksh93 code? There's not much to it. It simply sets an environment variable and calls atf-sh. What's more interesting is libtest.kshlib. In order to eliminate atf-ksh93, we would need to modify libtest.kshlib to run under /bin/sh. Alternatively, it may be easier to split libtest.kshlib into two files: a small /bin/sh-compatible that can be sourced by the ATF test programs, and a ksh93 script that only needs to be sourced by the ATF test cases. I'm working on integrating the dtrace testcases into kyua, then atf under Kyua as time permits, but I'm not rewriting the core test code (yet), because I want to reduce divergence with upstream. Why not just require ksh93 from ports? It's not that simple. It's certainly possible to put a require.progs ksh93 in the test case header. But you also need to use ksh93 features before invoking the test case script. For example, see zpool_upgrade_004_pos_body in tests/sys/cddl/zfs/tests/cli_root/zpool_upgrade/zpool_upgrade_test.sh . Notice how it sources some .kshlib scripts, then checks the $KEEP variable. Other tests do similar things. Perhaps they could be fixed by wrapping those lines in a here document that gets fed to ksh93. But that's very ugly. I'd rather fix all the tests to not require ksh93 before invoking the separate test case script. If you change the interpreter script from atf-ksh93 to atf-sh, you'll see errors like this: # kyua debug zfsd_test:zfsd_import_001_pos set: Illegal option -A set: Illegal option -A zfsd_test:zfsd_import_001_pos - broken: Premature exit; test case exited with code 2 -Alan ___ 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: [PATCH] Packet loss when 'control' messages are present with large data (sendmsg(2))
On Tue, Aug 26, 2014 at 1:51 PM, Mark Johnston ma...@freebsd.org wrote: On Tue, Aug 26, 2014 at 03:15:31PM -0400, John Baldwin wrote: On Tuesday, August 26, 2014 11:05:12 am Alan Somers wrote: On Mon, Aug 25, 2014 at 1:52 PM, John Baldwin j...@freebsd.org wrote: On Friday, August 22, 2014 01:34:28 PM Harald Schmalzbauer wrote: Bezüglich Yuri's Nachricht vom 02.09.2013 06:54 (localtime): Please check in this patch: http://www.freebsd.org/cgi/query-pr.cgi?pr=181741 Please MFC into 9.X Description of the problem is within PR. Thanks, Yuri Hello, I guess this fix should make it into 10.1. Can someone check please? A fix has to make into HEAD first. I've cc'd Alan who responded to the bug. Alan, note that glebius@ already committed the test case to HEAD a while ago. First, Gleb's testcase needs to be converted to ATF. This would be a good exercise for anybody who's new to ATF and wants some practice. Anybody interested? While that would be nice, I don't know that it's quite fair to require the test to be converted before working on a possible fix. The existing test doesn't seem that hard to run by hand: % cd work/freebsd/head/tools/regression/sockets/unix_passfd/ % make ... % ./unix_passfd beginning test1-simplesendfd test1-simplesendfd passed ... beginning test8-rigths+creds+payload unix_passfd: test8-rigths+creds+payload: recvmsg: 24 bytes received I only say this because in the bug followup you seemed to have described a possible solution so it seems that you would be able to develop a fix quicker than other folks since you are already familiar with the issues involved. (Also, you've fixed other related issues recently.) As it happens, I went ahead and did this anyway: https://reviews.freebsd.org/D689 BTW, is it just me, or is arcanist insanely slow? Usually arc diff --create or arc diff --update take many minutes to complete. Like, 30 minutes. I've been trying to do arc patch for nearly an hour now, but it hasn't completed yet. ___ 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: gbde destroy doesn't match man page?
On Tuesday, August 26, 2014 2:23:12 am Poul-Henning Kamp wrote: In message 2945485.zemf81r...@ralph.baldwin.cx, John Baldwin writes: On Saturday, August 23, 2014 10:16:42 AM Poul-Henning Kamp wrote: In message 20140820215522.ga92...@bewilderbeast.blackhelicopters.org, Michae l W. Lucas writes: Playing with GBDE for my FreeBSD disk book, on: # uname -a FreeBSD storm 11.0-CURRENT FreeBSD 11.0-CURRENT #6 r269010: Wed Jul 23 11:13:17 EDT 2014 mwlucas@storm:/usr/obj/usr/src/sys/GENERIC amd64 According to the man page, I should be able to destroy all copies of the key with gbde destroy device -n -1. It's in the examples. When I try it I get: I think that is an oversight in the code. Can you expand on this? I.e. what should the code do if it is fixed? Hmm, now that I think about it, -n doesn't make sense because any one of the four keys can open the volume as needed to blow away the masterkey. The manual page should just be fixed. Should the '-n -1' just be removed? I.e., is 'gbde destroy' sufficient to destroy all copies of the key? -- John Baldwin ___ 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 10 and zfsd
On Tue, Aug 26, 2014 at 1:04 PM, Mark Felder f...@freebsd.org wrote: August 26 2014 2:49 PM, Garrett Cooper yaneurab...@gmail.com wrote: Why not just require ksh93 from ports? Because zfsd is going to be in base, not in ports. Everything in base needs to work without any ports requirements. We have tests in base that require perl, and kyua itself comes from ports. Granted it's not ideal, but it works and it gives developers and test infrastructure people more flexibility with software instead of having to key it into a particular version in the base system. Also ksh93 has been... problematic. It has a history of breaking on i386, sparc64, current, etc. It's not exactly a reliable dependency. That's really unfortunate :(. If you have bug reports it'll provide ammunition for why this should be converted over to something more portable when I'm contributing patches back to IllumOS. I really didn't want to do it because the process for contributing back to IllumOS is so heavyweight, but reliability when running the tests is a must. Thanks! -Garrett ___ 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 10 and zfsd
On Tue, Aug 26, 2014 at 1:51 PM, Alan Somers asom...@freebsd.org wrote: On Tue, Aug 26, 2014 at 1:48 PM, Garrett Cooper yaneurab...@gmail.com wrote: On Aug 26, 2014, at 12:45, Alan Somers asom...@freebsd.org wrote: On Tue, Aug 26, 2014 at 1:39 PM, Mark Felder f...@freebsd.org wrote: August 26 2014 10:21 AM, Alan Somers asom...@freebsd.org wrote: Merged into the projects/zfsd/head branch by change 270604. Merging to head is blocked by three issues: a) The atf-ksh93 hack. The correct solution is to modify all the test programs (not the test cases) so they can run under /bin/sh. That will take some effort. Can you provide a link to the atf-ksh93 code? There's not much to it. It simply sets an environment variable and calls atf-sh. What's more interesting is libtest.kshlib. In order to eliminate atf-ksh93, we would need to modify libtest.kshlib to run under /bin/sh. Alternatively, it may be easier to split libtest.kshlib into two files: a small /bin/sh-compatible that can be sourced by the ATF test programs, and a ksh93 script that only needs to be sourced by the ATF test cases. I'm working on integrating the dtrace testcases into kyua, then atf under Kyua as time permits, but I'm not rewriting the core test code (yet), because I want to reduce divergence with upstream. Why not just require ksh93 from ports? It's not that simple. It's certainly possible to put a require.progs ksh93 in the test case header. But you also need to use ksh93 features before invoking the test case script. For example, see zpool_upgrade_004_pos_body in tests/sys/cddl/zfs/tests/cli_root/zpool_upgrade/zpool_upgrade_test.sh . Notice how it sources some .kshlib scripts, then checks the $KEEP variable. Other tests do similar things. Perhaps they could be fixed by wrapping those lines in a here document that gets fed to ksh93. But that's very ugly. I'd rather fix all the tests to not require ksh93 before invoking the separate test case script. If you change the interpreter script from atf-ksh93 to atf-sh, you'll see errors like this: # kyua debug zfsd_test:zfsd_import_001_pos set: Illegal option -A set: Illegal option -A zfsd_test:zfsd_import_001_pos - broken: Premature exit; test case exited with code 2 This should be plugged into kyua-testers though instead of hacking around ATF -- even if it's mostly a thin layer on top of the ATF tester; we should work towards a common goal with the DTrace/ZFS testing though because they sort of follow the same design patterns. My mentor jmmv@ might have valuable input to provide here in what should be done (I've CCed him). Thanks! -Garrett ___ 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: did tar(1) loose xz compression support in 11?
On Tue, Aug 26, 2014 at 1:23 PM, Lowell Gilbert freebsd-current-lo...@be-well.ilk.org wrote: Chris H bsd-li...@bsdforge.com writes: On 8/26/14 11:05 AM, Chris H wrote: Greetings, I'm currently testing 11. My build / install is from about 2 days ago. I generally use xz compression, when creating archives. But when I attempt the following: tar -cvJ --options xz:9 -f ./archive-name.tar.xz ./file it returns the following: tar: Undefined option: `xz:9' This has always worked in previous versions. Has the syntax changed, and the man(1) pages just haven't caught up? I use: tar -cJ --options xz:compression-level=1 .. on head. Are you using the right syntax? Apparently not. Using your example works as expected. RELENG_8, and RELENG_9 use short-hand; tar -cvJ --options xz:9 Why/when the change to long-hand? Seems a shame. Now I get to modify all my scripts, and such. :P Altho I don't suppose it'd be a big deal to back out (revert) the changes made to tar(1). :) I can't find any changes that would make the syntax change. At least, not in quite a long while. Therefore, this change may not be intentional. However, I looked at the the manual page from 9.3, and its description of the features looks the same as on the latest HEAD, and *doesn't* look like leaving out a key (in this case, compression-level) is ever compliant. You might try the latest (or older) libarchive from the ports, and compare its behaviour. Also, there are a number (amusingly many, in fact) of other ways of specifying these parameters that may be more convenient for you, so another look throught the tar(1) manual might save you a few minutes. Good luck. I've CCed kientzle@ for input. Thanks! -Garrett ___ 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 10 and zfsd
On Tue, Aug 26, 2014 at 3:32 PM, Garrett Cooper yaneurab...@gmail.com wrote: On Tue, Aug 26, 2014 at 1:51 PM, Alan Somers asom...@freebsd.org wrote: On Tue, Aug 26, 2014 at 1:48 PM, Garrett Cooper yaneurab...@gmail.com wrote: On Aug 26, 2014, at 12:45, Alan Somers asom...@freebsd.org wrote: On Tue, Aug 26, 2014 at 1:39 PM, Mark Felder f...@freebsd.org wrote: August 26 2014 10:21 AM, Alan Somers asom...@freebsd.org wrote: Merged into the projects/zfsd/head branch by change 270604. Merging to head is blocked by three issues: a) The atf-ksh93 hack. The correct solution is to modify all the test programs (not the test cases) so they can run under /bin/sh. That will take some effort. Can you provide a link to the atf-ksh93 code? There's not much to it. It simply sets an environment variable and calls atf-sh. What's more interesting is libtest.kshlib. In order to eliminate atf-ksh93, we would need to modify libtest.kshlib to run under /bin/sh. Alternatively, it may be easier to split libtest.kshlib into two files: a small /bin/sh-compatible that can be sourced by the ATF test programs, and a ksh93 script that only needs to be sourced by the ATF test cases. I'm working on integrating the dtrace testcases into kyua, then atf under Kyua as time permits, but I'm not rewriting the core test code (yet), because I want to reduce divergence with upstream. Why not just require ksh93 from ports? It's not that simple. It's certainly possible to put a require.progs ksh93 in the test case header. But you also need to use ksh93 features before invoking the test case script. For example, see zpool_upgrade_004_pos_body in tests/sys/cddl/zfs/tests/cli_root/zpool_upgrade/zpool_upgrade_test.sh . Notice how it sources some .kshlib scripts, then checks the $KEEP variable. Other tests do similar things. Perhaps they could be fixed by wrapping those lines in a here document that gets fed to ksh93. But that's very ugly. I'd rather fix all the tests to not require ksh93 before invoking the separate test case script. If you change the interpreter script from atf-ksh93 to atf-sh, you'll see errors like this: # kyua debug zfsd_test:zfsd_import_001_pos set: Illegal option -A set: Illegal option -A zfsd_test:zfsd_import_001_pos - broken: Premature exit; test case exited with code 2 This should be plugged into kyua-testers though instead of hacking around ATF -- even if it's mostly a thin layer on top of the ATF tester; we should work towards a common goal with the DTrace/ZFS testing though because they sort of follow the same design patterns. My mentor jmmv@ might have valuable input to provide here in what should be done (I've CCed him). Adding a ksh93 tester to Kyua was previously discussed on kyua-discuss. But it was basically shot down. https://groups.google.com/forum/#!topic/kyua-discuss/w8oJHeZXuro Porting, in whole or in part, the tests to /bin/sh is time consuming, but it's the only option that satisfies everyone. -Alan ___ 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: gbde destroy doesn't match man page?
In message 201408261723.53428@freebsd.org, John Baldwin writes: Hmm, now that I think about it, -n doesn't make sense because any one of the four keys can open the volume as needed to blow away the masterkey. The manual page should just be fixed. Should the '-n -1' just be removed? I.e., is 'gbde destroy' sufficient to destroy all copies of the key? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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: gbde destroy doesn't match man page?
In message 201408261723.53428@freebsd.org, John Baldwin writes: Hmm, now that I think about it, -n doesn't make sense because any one of the four keys can open the volume as needed to blow away the masterkey. The manual page should just be fixed. Should the '-n -1' just be removed? I.e., is 'gbde destroy' sufficient to destroy all copies of the key? (Sorry about previous empty reply) Yes, the -n isn't needed because it doesn't operate on any specific key but all of them. This differs from for instance setkey where you may use key number 1 to set a new key number 2. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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: [PATCH] Packet loss when 'control' messages are present with large data (sendmsg(2))
On 26 August 2014 14:22, Alan Somers asom...@freebsd.org wrote: On Tue, Aug 26, 2014 at 1:51 PM, Mark Johnston ma...@freebsd.org wrote: On Tue, Aug 26, 2014 at 03:15:31PM -0400, John Baldwin wrote: On Tuesday, August 26, 2014 11:05:12 am Alan Somers wrote: On Mon, Aug 25, 2014 at 1:52 PM, John Baldwin j...@freebsd.org wrote: On Friday, August 22, 2014 01:34:28 PM Harald Schmalzbauer wrote: Bezüglich Yuri's Nachricht vom 02.09.2013 06:54 (localtime): Please check in this patch: http://www.freebsd.org/cgi/query-pr.cgi?pr=181741 Please MFC into 9.X Description of the problem is within PR. Thanks, Yuri Hello, I guess this fix should make it into 10.1. Can someone check please? A fix has to make into HEAD first. I've cc'd Alan who responded to the bug. Alan, note that glebius@ already committed the test case to HEAD a while ago. First, Gleb's testcase needs to be converted to ATF. This would be a good exercise for anybody who's new to ATF and wants some practice. Anybody interested? While that would be nice, I don't know that it's quite fair to require the test to be converted before working on a possible fix. The existing test doesn't seem that hard to run by hand: % cd work/freebsd/head/tools/regression/sockets/unix_passfd/ % make ... % ./unix_passfd beginning test1-simplesendfd test1-simplesendfd passed ... beginning test8-rigths+creds+payload unix_passfd: test8-rigths+creds+payload: recvmsg: 24 bytes received I only say this because in the bug followup you seemed to have described a possible solution so it seems that you would be able to develop a fix quicker than other folks since you are already familiar with the issues involved. (Also, you've fixed other related issues recently.) As it happens, I went ahead and did this anyway: https://reviews.freebsd.org/D689 BTW, is it just me, or is arcanist insanely slow? Usually arc diff --create or arc diff --update take many minutes to complete. Like, 30 minutes. I've been trying to do arc patch for nearly an hour now, but it hasn't completed yet. It's you. it's very quick for me. -a ___ 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 10 and zfsd
On Tue, Aug 26, 2014 at 2:43 PM, Alan Somers asom...@freebsd.org wrote: ... Adding a ksh93 tester to Kyua was previously discussed on kyua-discuss. But it was basically shot down. https://groups.google.com/forum/#!topic/kyua-discuss/w8oJHeZXuro Maybe the idea just needs to be approached from a different angle like I did with /bin/sh/tests ( https://svnweb.freebsd.org/base/head/bin/sh/tests/functional_test.sh?revision=269902view=markup )? I know that with DTrace at least, it uses dtest.pl, which implements its own test discovery mechanism, which should be easy to hook into atf and produce testcases for dynamically. Some additional logic might be required to work around testcases that fail today on FreeBSD or cause the system to livelock/panic (e.g. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192906 ), but writing in simple hooks for this shouldn't be hard. Porting, in whole or in part, the tests to /bin/sh is time consuming, but it's the only option that satisfies everyone. Perhaps. I'm lazier nowadays and prefer not chasing after the perfect solution if I can help it (especially because it tends to bite me in the rear later). Thanks! -Garrett ___ 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: did tar(1) loose xz compression support in 11?
Chris H bsd-li...@bsdforge.com writes: On 8/26/14 11:05 AM, Chris H wrote: Greetings, I'm currently testing 11. My build / install is from about 2 days ago. I generally use xz compression, when creating archives. But when I attempt the following: tar -cvJ --options xz:9 -f ./archive-name.tar.xz ./file it returns the following: tar: Undefined option: `xz:9' This has always worked in previous versions. Has the syntax changed, and the man(1) pages just haven't caught up? I use: tar -cJ --options xz:compression-level=1 .. on head. Are you using the right syntax? Apparently not. Using your example works as expected. RELENG_8, and RELENG_9 use short-hand; tar -cvJ --options xz:9 Why/when the change to long-hand? Seems a shame. Now I get to modify all my scripts, and such. :P Altho I don't suppose it'd be a big deal to back out (revert) the changes made to tar(1). :) I can't find any changes that would make the syntax change. At least, not in quite a long while. Therefore, this change may not be intentional. However, I looked at the the manual page from 9.3, and its description of the features looks the same as on the latest HEAD, and *doesn't* look like leaving out a key (in this case, compression-level) is ever compliant. You might try the latest (or older) libarchive from the ports, and compare its behaviour. Also, there are a number (amusingly many, in fact) of other ways of specifying these parameters that may be more convenient for you, so another look throught the tar(1) manual might save you a few minutes. Thank you, Lowell. For your extremely informative reply. Curious. The man page I read from my freshly built 11-CURRENT indicates the following: xz:compression-level A decimal integer from 0 to 9 specifying the xz compres- sion level. As I have always read that (interpreted it). It meant: xz:decimal-number (0-9) Which is what I've always used. I haven't grepped ports||src yet. But if it makes any difference, it came from src -- build/install world. I'll do some poking around. But all my other boxes (RELENG_8 RELENG_9) use xz:decimal-number. Thanks again, Lowell. For taking the time to respond. Greatly appreciated. --Chris Good luck. ___ 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 ___ 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: did tar(1) loose xz compression support in 11?
Chris H wrote this message on Tue, Aug 26, 2014 at 16:32 -0700: Chris H bsd-li...@bsdforge.com writes: On 8/26/14 11:05 AM, Chris H wrote: Greetings, I'm currently testing 11. My build / install is from about 2 days ago. I generally use xz compression, when creating archives. But when I attempt the following: tar -cvJ --options xz:9 -f ./archive-name.tar.xz ./file it returns the following: tar: Undefined option: `xz:9' This has always worked in previous versions. Has the syntax changed, and the man(1) pages just haven't caught up? I use: tar -cJ --options xz:compression-level=1 .. on head. Are you using the right syntax? Apparently not. Using your example works as expected. RELENG_8, and RELENG_9 use short-hand; tar -cvJ --options xz:9 Why/when the change to long-hand? Seems a shame. Now I get to modify all my scripts, and such. :P Altho I don't suppose it'd be a big deal to back out (revert) the changes made to tar(1). :) I can't find any changes that would make the syntax change. At least, not in quite a long while. Therefore, this change may not be intentional. However, I looked at the the manual page from 9.3, and its description of the features looks the same as on the latest HEAD, and *doesn't* look like leaving out a key (in this case, compression-level) is ever compliant. You might try the latest (or older) libarchive from the ports, and compare its behaviour. Also, there are a number (amusingly many, in fact) of other ways of specifying these parameters that may be more convenient for you, so another look throught the tar(1) manual might save you a few minutes. Thank you, Lowell. For your extremely informative reply. Curious. The man page I read from my freshly built 11-CURRENT indicates the following: xz:compression-level A decimal integer from 0 to 9 specifying the xz compres- sion level. As I have always read that (interpreted it). It meant: xz:decimal-number (0-9) Which is what I've always used. I haven't grepped ports||src yet. But if it makes any difference, it came from src -- build/install world. I'll do some poking around. But all my other boxes (RELENG_8 RELENG_9) use xz:decimal-number. Thanks again, Lowell. For taking the time to respond. Greatly appreciated. Could it be that previous versions were ignoring the option and not giving you an error? It looks like that was the case on my 9.1-PR box: $tar -cJf test.txz *.patch *.c testcrypt *.h; ls -l test.txz -rw--- 1 jmg wheel 38956 Aug 26 17:33 test.txz $tar --options xz:9 -cJf test.txz *.patch *.c testcrypt *.h; ls -l test.txz -rw--- 1 jmg wheel 38956 Aug 26 17:33 test.txz $tar --options xz:1 -cJf test.txz *.patch *.c testcrypt *.h; ls -l test.txz -rw--- 1 jmg wheel 38956 Aug 26 17:33 test.txz $tar --options xz:compression-level=1 -cJf test.txz *.patch *.c testcrypt *.h; ls -l test.txz -rw--- 1 jmg wheel 41772 Aug 26 17:34 test.txz $tar --options xz:compression-level=9 -cJf test.txz *.patch *.c testcrypt *.h; ls -l test.txz -rw--- 1 jmg wheel 38956 Aug 26 17:34 test.txz -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ 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: did tar(1) loose xz compression support in 11?
On Aug 26, 2014, at 11:05 AM, Chris H bsd-li...@bsdforge.com wrote: Greetings, I'm currently testing 11. My build / install is from about 2 days ago. I generally use xz compression, when creating archives. But when I attempt the following: tar -cvJ --options xz:9 -f ./archive-name.tar.xz ./file it returns the following: tar: Undefined option: `xz:9' This has always worked in previous versions. Has the syntax changed, and the man(1) pages just haven't caught up? I can’t see any evidence in libarchive’s source that this ever worked. However, there was some work done recently to improve error reporting from the options processor. It’s quite possible that —options xz:9 used to just be ignored and now it’s reporting an error. Tim ___ 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: did tar(1) loose xz compression support in 11?
On Tue, 26 Aug 2014, Tim Kientzle wrote: On Aug 26, 2014, at 11:05 AM, Chris H bsd-li...@bsdforge.com wrote: Greetings, I'm currently testing 11. My build / install is from about 2 days ago. I generally use xz compression, when creating archives. But when I attempt the following: tar -cvJ --options xz:9 -f ./archive-name.tar.xz ./file it returns the following: tar: Undefined option: `xz:9' This has always worked in previous versions. Has the syntax changed, and the man(1) pages just haven't caught up? I can’t see any evidence in libarchive’s source that this ever worked. The man page is a little confusing. Here it says: --options options Select optional behaviors for particular modules. The argument is a text string containing comma-separated keywords and values. These are passed to the modules that handle particular formats to control how those formats will behave. Each option has one of the following forms: key=value The key will be set to the specified value in every module that supports it. Modules that do not support this key will ignore it. Then below, after the last option, it says: ... zip:compression=type Use type as compression method. Supported values are store (uncompressed) and deflate (gzip algorithm). If a provided option is not supported by any module, that is a fatal error. The first states that it is ignored, the latter states that it is a fatal error. The meaning of any module is subtle, at least for my feeble brain ;-) Also, the syntax for [lr]zip:compression=type is very clear, whereas the syntax for compression-level keys omit the =value. -- DE ___ 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
