receive -F from incremental non-replication send stream deletes destination snapshots

[rfehren]

This is with zfs 0.6.5.6
According to the man page receive -F should delete "non-source" snapshots on the destination side only if the send stream was generated with "-R -[iI]". But it does so (randomly) also when sending just with a simple "-i".

Example:

• Situation before send receive

Existing local snapshots:
----------------------------------------------------------
NAME                            USED  CREATION
ssd/build@daily-1                  0  Tue May  3 15:56 2016
ssd/build@daily-2                  0  Tue May  3 15:52 2016
ssd/build@hourly-1                 0  Tue May  3 15:52 2016
ssd/build@hourly-2                 0  Tue May  3 15:33 2016

Existing snapshots on backup server '*LOCAL*':
----------------------------------------------------------
NAME                            USED  CREATION
sata/bak/ssd/build@daily-2        8K  Tue May  3 15:52 2016
sata/bak/ssd/build@daily-3        8K  Tue May  3 15:34 2016
sata/bak/ssd/build@daily-4        8K  Tue May  3 15:26 2016
sata/bak/ssd/build@hourly-1        0  Tue May  3 15:52 2016

• Execute
  zfs send -i ssd/build@daily-2 ssd/build@daily-1 | zfs receive -F sata/bak/ssd/build
• Situation after send receive

Existing local snapshots:
----------------------------------------------------------
NAME                            USED  CREATION
ssd/build@daily-1                  0  Tue May  3 15:56 2016
ssd/build@daily-2                  0  Tue May  3 15:52 2016
ssd/build@hourly-1                 0  Tue May  3 15:52 2016
ssd/build@hourly-2                 0  Tue May  3 15:33 2016

Existing snapshots on backup server '*LOCAL*':
----------------------------------------------------------
NAME                            USED  CREATION
sata/bak/ssd/build@daily-1         0  Tue May  3 15:56 2016
sata/bak/ssd/build@daily-2        8K  Tue May  3 15:52 2016
sata/bak/ssd/build@daily-3        8K  Tue May  3 15:34 2016
sata/bak/ssd/build@daily-4        8K  Tue May  3 15:26 2016

Note that sata/bak/ssd/build@hourly-1 is gone.

[eborisch]

As has been discussed previously in #3010, I (and others) avoid using recv -F unless you really what the behavior it provides. It is likely not the right choice for scripted / automated backups, as an accidental deletion of a child file system (accidents happen, that's at least part of why you backup, right?) on the source will get propagated (and happily applied) to the backup, which doesn't fit my definition of backup.

There's nothing wrong with -F, but it shouldn't be an everyday use flag, but rather a "things got wonky and now I need to repair it carefully" flag.

[rfehren]

Thanks for the comments.
@ptx0: There were a few inherited properties which were different on the receiving side. When I corrected them, using -F became unnecessary. Things work fine now.