* Illumos zfs issue #3035 [1] LZ4 compression support in ZFS.
LZ4 is a new high-speed BSD-licensed compression algorithm created
by Yann Collet that delivers very high compression and decompression
performance compared to lzjb (>50% faster on compression, >80% faster
on decompression and around 3x faster on compression of incompressible
data), while giving better compression ratio [1].
This version of LZ4 corresponds to upstream's [2] revision 85.
Please note that for obvious reasons this is not backward read
compatible. This means once a pool have LZ4 compressed data, these
data can no longer be read by older ZFS implementations.
Local changes:
- On-stack hash table disabled and using kernel slab allocator
instead, at this time. This requires larger kernel thread stack
for zio workers. This may change in the future should we adjusted
the zio workers' thread stack size.
- likely and unlikely will be undefined if they are already defined,
this is required for i386 XEN build.
- Removed De Bruijn sequence based __builtin_ctz family of builtins
in favor of the latter. Both GCC and clang supports these builtins.
- Changed the way the LZ4 code detects endianness.
- Manual pages modifications to mention the feature based on Illumos
counterpart.
- Boot loader changes to make it support LZ4 decompression.
[1] https://www.illumos.org/issues/3035
[2] http://code.google.com/p/lz4/source/list
Obtained from: Illumos (13921:9d721847e469)
Tested on: FreeBSD/amd64
MFC after: 1 month
e2fs_maxcontig was modelled after UFS when bringing the
"Orlov allocator" to ext2. On UFS fs_maxcontig is kept in the
superblock and is used by userland tools (fsck and growfs),
In ext2 this information is volatile so it is not available
for userland tools, so in this case it doesn't have sense
to carry it in the in-memory superblock.
Also remove a pointless check for MAX(1, x) > 0.
Submitted by: Christoph Mallon
MFC after: 2 weeks
According to the README file [1] the 12u variant, unlike
the 12g variant, contains no copyleft code. It is therefore
convenient to keep using the original versioning scheme to
prevent confusions.
[1] http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/patch/README
Document the need for the setuid bit and how to set it.
Explain why it isn't set by default, and suggest simply adding users
to groups instead.
PR: docs/167741
MFC after: 3 weeks
GZIP compressed manuals to appear in ./src instead of the appropriate obj dir.
PR: conf/175844
Submitted by: Dominique Goncalves <dominique.goncalves@gmail.com>
* Add the superg.h header to allow ieee80211_check_ff() to work
* Since the assert stuff creates assertions based on line numbers and there
was a conflict, just nudge things down a bit.
crappy 802.11n performance, sigh.)
With the AR5416, aggregates need to be limited to 8KiB if RTS/CTS is
enabled. However, larger aggregates were going out with RTSCTS enabled.
The following was going on:
* The first buffer in the list would have RTS/CTS enabled in
bf->bf_state.txflags;
* The aggregate would be formed;
* The "copy over the txflags from the first buffer" logic that I added
blanked the RTS/CTS TX flags fields, and then copied the bf_first
RTS/CTS flags over;
* .. but that'd cause bf_first to be blanked out! And thus the flag
was cleared;
* So the rest of the aggregate formation would run with those flags
cleared, and thus > 8KiB aggregates were formed.
The driver is now (again) correctly limiting aggregate formation for
the AR5416 but there are still other pending issues to resolve.
Tested:
* AR5416, STA mode
A special gfs vnode corresponds to that object.
A regular zfs vnode must not be returned.
This should be upstreamed.
Reported by: pluknet
Submitted by: rmacklem
Tested by: pluknet
MFC after: 10 days
Older entries should be 'before' newer entries in the new buffer too
and there should be no zero-filled gap between them.
Pointed out by: jhb
MFC after: 3 days
X-MFC with: r246282
Now it outputs fixed files, which use constants provided by the C standard
library to determine appropriate values for the target machine.
Before, mksyntax inspected the host machine which resulted in subtle
breakage if e.g. char is signed on the host and unsigned on the target such
as when cross-compiling on x86 for ARM.
Tested using -funsigned-char on amd64. Compiling build-tools without it and
sh itself with it causes various tests to fail without this change but not
with this change. With consistent -funsigned-char, tests pass with or
without this change.
The mksyntax program could be removed and syntax.c and syntax.h committed to
the repository.
Submitted by: Christoph Mallon
MFC after: 2 weeks
* Added hwmp_update_transmitter function that checks if the metric
to the transmitter have improved. If old FI is invalid or metric
is larger the FI to the transmitter is updated occurdingly.
This is a recommendation from the 802.11 2012 standard, table 13-9;
Approved by: adrian (mentor)
* When calling ieee80211_mesh_rt_flush_peer, the rt->rt_dest argument
should not be passed because it can get freed before invalidating
the other routes that depends on it to compare with next_hop.
Use PERR_DADDR(i) instead;
Approved by: adrian (mentor)
* The standard is unclear about what should happen in case a mesh STA (not
marked as a mesh gate) recevies a PREQ for a destination that is marked
as proxy. Solution for now is not to do intermediate reply at all, and
let the PREQ reach the mesh gate;
Approved by: adrian (mentor)
* Original PREP frame is transmitted only by the target mesh STA or the
mesh STA that is the proxy target;
* Fixed so that metric value is not over written incorrectly in
hwmp_recv_preq for when replying back with a PREP;
Approved by: adrian (mentor)
This is a code re-write. ic->raw_xmit need a pointer to ieee80211_node
for the destination node (da). I have reorganized the code so that
a pointer to the da node is searched for in the end & in one place.
* Make mesh_find_txnode public to be used by HWMP, renamed to
ieee80211_mesh_finx_txnode;
* changed the argument from ieee80211_node to ieee80211vap for all
hwmp_send_* functions;
* removed the 'sa' argument from hwmp_send_* functions as all HWMP frames
have the source address equal to vap->iv_myaddr;
* Modified hwmp_send_action so that if da is MULTCAST ni=vap->iv_bss
otherwise we called ieee80211_mesh_find_txnode. Also no need to hold
a reference in this functions if da is not MULTICAST as by finding the
node it became referenced in ieee80211_find_txnode;
Approved by: adrian (mentor)
* Modified mesh_find_txnode to be able to handle proxy marked entries by
recursively calling itself to find the txnode towards the active mesh gate;
* Mesh Gate: Added a new function that transmits data frames
similar to ieee80211_start;
* Modified ieee80211_mesh_forward_to_gates so that:
+ Frames are duplicated and sent to each valid Mesh Gate;
+ Route is marked invalid before return of function, this is
because we dont know yet which Mesh Gate is we will use;
Approved by: adrian (mentor)
* Send frames that have no path to a known valid Mesh Gate;
* Added the function ieee80211_mesh_forward_to_gates that sends the frame
to the first found Mesh Gate in the forwarding information;
* If we try to discover again while we are discovering queue frame,
the discovery callout will send the frames either to mesh gates
or discards them silently;
* Queue frame also if we try to discover to frequently;
Approved by: adrian (mentor)
* Add function ieee80211_mesh_mark_gate in ieee80211_mesh.h;
* When received a proactive PREQ or RANN with corresponding mesh gate
flag set, create a new entry in the known mesh gate list;
Approved by: adrian (mentor)
* Modified mesh_recv_action_meshgate to do following:
+ if mesh STA already knows the mesh gate of the recevied GANN frame
+ if mesh gate is know, check seq number according to 802.11 standard
+ if mesh gate is not know, add it to the list of known mesh gates
+ if forwarding is enabled and ttl >= 1 then propagate the GANN frame;
* Declare a new malloc type M_80211_MESH_GT_RT;
* Declare a struct to store GANN information, ieee80211_mesh_gate_route. And
add it as a TAILQ list to ieee80211_mesh_state;
Approved by: adrian (mentor)
A Mesh Gate should transmit a Mesh Action frame containing
ieee80211_meshgann_ie as its only information element periodically
every ieee80211_mesh_gateint ms. Unless the mesh gate is also configure
as a ROOT, then these frames should not be send.
This is according to 802.11 2012 standard;
* Introduce new SYSCTL net.wlan.mesh.gateint, with 10s default;
* Add two new functions mesh_gatemode_setup and mesh_gatemode_cb. This
is similar to how HWMP setups up a callout;
* Add two new action handlers mesh_recv_action_meshgate and
mesh_send_action_meshgate;
* Added ieee80211_add_meshgate to ieee80211_mesh.h;
* Modified mesh_send_action to look similar to hwmp_send_action. This is
because we need to send out broadcast management frames.
* Introduced a new flag for mesh state IEEE80211_MESHFLAGS_ROOT. This flag
is now set by HWMP code when a mesh STA is configured as a ROOT. This
is then checked by mesh_gatemode_cb before scheduling a new callout;
* Added to new field to ieee80211_mesh_state:
+ struct callout ms_gatetimer
+ ieee80211_mesh_seq ms_gateseq;
Approved by: adrian (mentor)
