7

In order to use the new encryption method in TrueNAS 12 I copied all data from a legacy encrypted FreeNAS pool to a newly formatted pool via a replication task.

After replication there seems to be almost a GiB missing on the target pool:

Source pool after replication: 8.06 TiB used, 733.91 GiB available

Target pool after replication: 7.24 TiB used, 1.56 TiB available

For replication I used these settings (basic mode):

To find out what is missing a diff would take too long.

I tried rsync -avun --delete $TARGET $SOURCE | grep "^deleting " but there was no output.

What else could I do to check for the missing files on the target in reasonable time? Is there something ZFS-related that might take up space and hasn’t been copied over by the replication task? What could that be?

Andept
  • 73
  • 5

1 Answers1

9

The difference can be related to different pool or dataset configuration (mirror vs raidz, ashift value, recordsize, compression, etc). If you sent data via send/recv, no data should be lost ever. This seems confirmed by the output of your rsync command.

If you can, please show the output of the following commands on both source and destination (feel free to redact the output as required):

zpool status
zpool get all
zfs get all
shodanshok
  • 47,711
  • 7
  • 111
  • 180
  • 1
    Thanks for these commands! Comparing `zfs get all` shows that `zstd_compress` is disabled on the source and enabled on the target. Guess that’s the solution. – Andept Apr 21 '21 at 16:25
  • What is `send/recv`? Does ZFS replication (configured from TrueNAS web UI) use this? – Andept Apr 21 '21 at 16:26
  • 3
    @Andept yeah, if compression is enabled on the target only, this easily explain the different size. `zfs send` and `zfs recv` are the ZFS native tools for filesystem replication, and TrueNAS replication should use them as far I know. – shodanshok Apr 21 '21 at 18:31