私はLinuxでZFSを使用していますが、ファイルの実際のディスク使用量（「du」と報告されている）がなぜあちこちに表示されるのか混乱しています。
自動サイズ変更「on」を除くすべてのデフォルト値を使用して、ハードウェアDell PERC RAID（/ dev / sdbのみ）に「vault」というプールを作成しました。
その後、次のようにボリュームを作成しました。
-o予約=2040G -oクォータ=2040G -oサイズ変更=4k -o acltype=posixacl
その後、ext4ボリュームを同期しました。たとえば、このボリュームにはそれぞれ13104バイトと11264バイトのサイズの2つのデータファイル（Matlab * .matファイル）があります。 ext4ファイルシステムでは、このファイルのduは、それぞれ4Kブロックサイズに対応する16Kと12Kを意味します。 4K未満のファイルは常にduの4Kを表示します。
対照的に、ZFS duでは、2つのファイルにそれぞれ25Kと21Kが表示され、1バイトのファイルでは4.5Kが表示されます。私はさまざまなメタデータを使用しているため、後者の追加0.5Kはそれほど重要ではないと思います。別の<4Kファイルを実行しましたが、返された結果はまさに4Kでした。最も混乱しているのは、* .matファイルのduが「実際の」データサイズのほぼ2倍の理由です。
ベストアンサー1
これらの情報を確認するために使用できますzdb。インデックスノードとデータセットのみをインポートするだけです。たとえば、データセット名がある場合は、を使用してinode番号を確認してから情報をダンプtank/fooできます。ls -izdb -ddddd tank/foo $INODE
私のコンピュータの例は次のとおりです。
# cd /var/tmp
# mkfile 13104 file1
# ls -i file1
4125 file1
# zdb -ddddd rpool/VARSHARE/tmp 4125
Dataset rpool/VARSHARE/tmp [ZPL], ID 4128, cr_txg 928175, 8.24G, 1223 objects, rootbp DVA[0]=<0:1f62907a00:200:STD:1> DVA[1]=<0:f4a2eda00:200:STD:1> [L0 DMU objset] fletcher4 lzjb LE unique unencrypted size=800L/200P birth=14962025L/14962025P fill=1223 contiguous 2-copy cksum=1b152e5f60:7b661ed2ecb:1445f97091785:278e0e37baf85b
Object lvl iblk dblk dsize lsize %full type
4125 1 16K 13.0K 13.0K 13.0K 100.00 ZFS plain file
168 bonus System attributes
dnode flags: USED_BYTES USERUSED_ACCOUNTED
dnode maxblkid: 0
path /file1
uid 0
gid 0
atime Fri Sep 7 18:48:00 2018
mtime Fri Sep 7 18:48:00 2018
ctime Fri Sep 7 18:48:00 2018
crtime Fri Sep 7 18:48:00 2018
gen 14962023
mode 0100600
size 13104
parent 4
links 1
pflags 0x40800000204
Indirect blocks:
0 L0 0:0x1f55eb0200:0x3400 0x3400L/0x3400P F=1 B=14962023/14962023 ---
segment [000000000000000000, 0x0000000000003400) size 13.0K
#
これにより、データサイズとファイルが消費するメタデータ（「間接ブロック」と呼ばれる）の量に関するアイデアを得ることができます。
この場合、正確に13kブロックを割り当て、単一の16k間接ブロックを使用します。したがって、29kを使用して13kファイルを保存します。おそらく数字も似ていると思います。
16k「iblk」は圧縮されている可能性が高いため、物理的に4kしか占有しません。