Add sending large block section

FAQ.md

@@ -12,7 +12,9 @@
 - [Changing /dev/ names on an existing pool](#changing-dev-names-on-an-existing-pool)
 - [The /etc/zfs/zpool.cache file](#the-etczfszpoolcache-file)
 - [Generating a new /etc/zfs/zpool.cache file](#generating-a-new-etczfszpoolcache-file)
-- [hole_birth Bugs](#hole_birth-bugs)
+- [Sending and Receiving Streams](#sending-and-receiving-streams)
+  * [hole_birth Bugs](#hole_birth-bugs)
+  * [Sending Large Blocks](#sending-large-blocks)
 - [CEPH/ZFS](#cephzfs)
   * [ZFS Configuration](#zfs-configuration)
   * [CEPH Configuration (ceph.conf}](#ceph-configuration-cephconf)
@@ -232,8 +234,9 @@ Conversely the cache file can be disabled by setting `cachefile=none`.  This is
 ```
 $ zpool set cachefile=none tank
 ```
+## Sending and Receiving Streams
 
-## hole_birth Bugs
+### hole_birth Bugs
 
 The hole_birth feature has/had bugs, the result of which is that, if you do a `zfs send -i` (or `-R`, since it uses `-i`) from an affected dataset, the receiver *will not see any checksum or other errors, but will not match the source*.
 
@@ -241,6 +244,13 @@ ZoL versions 0.6.5.8 and 0.7.0-rc1 (and above) default to ignoring the faulty me
 
 For more details, see the [[hole_birth FAQ]].
 
+### Sending Large Blocks
+
+When sending incremental streams which contain large blocks (>128K) the `--large-block` flag must be specified.  Inconsist use of the flag between incremental sends can result in files being incorrectly zeroed when they are received.  Raw encrypted send/recvs automatically imply the `--large-block` flag and are therefore unaffected.
+
+For more details, see [issue 6224](https://github.com/zfsonlinux/zfs/issues/6224).
+
+
 ## CEPH/ZFS
 
 There is a lot of tuning that can be done that's dependent on the workload that is being put on CEPH/ZFS, as well as some general guidelines. Some are as follow;