ZFS zvolスナップショットをローカルにマウントすると、「無効な引数」が発生します
ZFSzvolのスナップショットをマウントしようとしています。 zvolにはext2パーティションが必要です（CentOS VM zvolが現在iSCSIによって共有されている）によって証明されます）：
[root@test-vm ~]# file - < /dev/sdb
/dev/stdin: x86 boot sector; partition 1: ID=0x83, starthead 4, startsector 256, 6291200 sectors, code offset 0xb8
[root@test-vm ~]# file - < /dev/sdb1
/dev/stdin: Linux rev 1.0 ext2 filesystem data (mounted or unclean) (large files)
ただし、mountは常にInvalid argumentを返します。
[root@freenas] /dev/zvol/vol01# ls
./ zvol01 zvol01@backups1 zvol01@manual-20140521s1 zvol01@manual-20140522s1
../ zvol01@backup zvol01@manual-20140521 zvol01@manual-20140522
[root@freenas] /dev/zvol/vol01# file - < zvol01
/dev/stdin: x86 boot sector; partition 1: ID=0x83, starthead 4, startsector 256, 6291200 sectors, code offset 0xb8
[root@freenas] /dev/zvol/vol01# file - < zvol01@backup
/dev/stdin: x86 boot sector; partition 1: ID=0x83, starthead 4, startsector 256, 6291200 sectors, code offset 0xb8
[root@freenas] /dev/zvol/vol01# file - < zvol01@backups1
/dev/stdin: data
[root@freenas] /dev/zvol/vol01# mkdir /tmp/zvol01
[root@freenas] /dev/zvol/vol01# mount -t ext2fs -r /dev/zvol/vol01/zvol01@backup /tmp/zvol01
mount: /dev/zvol/vol01/zvol01@backup: Invalid argument
[root@freenas] /dev/zvol/vol01# mount -t ext2fs -r /dev/zvol/vol01/zvol01@backups1 /tmp/zvol01
mount: /dev/zvol/vol01/zvol01@backups1: Invalid argument
zvol01@backups1が正しいターゲット（つまり、ブロックデバイス上の最初のパーティションzvol01@backup）であると推測します。どちらもInvalid argumentを返します。
ここで何が欠けていますか？
編集
要求に応じて、zfs listおよびzfs get all ..の出力.
[root@freenas] ~# zfs list
NAME USED AVAIL REFER MOUNTPOINT
vol01 25.6G 358G 232K /mnt/vol01
vol01/.system 1.44M 358G 244K /mnt/vol01/.system
vol01/.system/cores 209K 358G 209K /mnt/vol01/.system/cores
vol01/.system/samba4 506K 358G 506K /mnt/vol01/.system/samba4
vol01/.system/syslog 517K 358G 517K /mnt/vol01/.system/syslog
vol01/ds01 784M 358G 784M /mnt/vol01/ds01
vol01/zvol01 24.9G 382G 113M -
[root@freenas] ~# zfs get all vol01/zvol01
NAME PROPERTY VALUE SOURCE
vol01/zvol01 type volume -
vol01/zvol01 creation Wed May 21 20:29 2014 -
vol01/zvol01 used 24.9G -
vol01/zvol01 available 382G -
vol01/zvol01 referenced 113M -
vol01/zvol01 compressratio 1.00x -
vol01/zvol01 reservation none default
vol01/zvol01 volsize 24G local
vol01/zvol01 volblocksize 4K -
vol01/zvol01 checksum on default
vol01/zvol01 compression lz4 inherited from vol01
vol01/zvol01 readonly off default
vol01/zvol01 copies 1 default
vol01/zvol01 refreservation 24.8G local
vol01/zvol01 primarycache all default
vol01/zvol01 secondarycache all default
vol01/zvol01 usedbysnapshots 215K -
vol01/zvol01 usedbydataset 113M -
vol01/zvol01 usedbychildren 0 -
vol01/zvol01 usedbyrefreservation 24.8G -
vol01/zvol01 logbias latency default
vol01/zvol01 dedup off inherited from vol01
vol01/zvol01 mlslabel -
vol01/zvol01 sync standard default
vol01/zvol01 refcompressratio 1.00x -
vol01/zvol01 written 221K -
vol01/zvol01 logicalused 74.4M -
vol01/zvol01 logicalreferenced 74.3M -
[root@freenas] ~# zfs get all vol01/zvol01@backup
NAME PROPERTY VALUE SOURCE
vol01/zvol01@backup type snapshot -
vol01/zvol01@backup creation Thu May 22 1:48 2014 -
vol01/zvol01@backup used 215K -
vol01/zvol01@backup referenced 113M -
vol01/zvol01@backup compressratio 1.00x -
vol01/zvol01@backup devices on default
vol01/zvol01@backup exec on default
vol01/zvol01@backup setuid on default
vol01/zvol01@backup xattr on default
vol01/zvol01@backup nbmand off default
vol01/zvol01@backup primarycache all default
vol01/zvol01@backup secondarycache all default
vol01/zvol01@backup defer_destroy off -
vol01/zvol01@backup userrefs 0 -
vol01/zvol01@backup mlslabel -
vol01/zvol01@backup refcompressratio 1.00x -
vol01/zvol01@backup written 113M -
vol01/zvol01@backup clones -
vol01/zvol01@backup logicalused 0 -
vol01/zvol01@backup logicalreferenced 74.3M -
[root@freenas] /dev/zvol/vol01# gpart show
=> 63 16777153 da0 MBR (8.0G)
63 1930257 1 freebsd [active] (942M)
1930320 63 - free - (31k)
1930383 1930257 2 freebsd (942M)
3860640 3024 3 freebsd (1.5M)
3863664 41328 4 freebsd (20M)
3904992 12872224 - free - (6.1G)
=> 0 1930257 da0s1 BSD (942M)
0 16 - free - (8.0k)
16 1930241 1 !0 (942M)
=> 34 286749421 da1 GPT (136G)
34 94 - free - (47k)
128 4194304 1 freebsd-swap (2.0G)
4194432 282555023 2 freebsd-zfs (134G)
=> 34 286749421 da2 GPT (136G)
34 94 - free - (47k)
128 4194304 1 freebsd-swap (2.0G)
4194432 282555023 2 freebsd-zfs (134G)
=> 34 286749421 da3 GPT (136G)
34 94 - free - (47k)
128 4194304 1 freebsd-swap (2.0G)
4194432 282555023 2 freebsd-zfs (134G)
=> 34 286749421 da4 GPT (136G)
34 94 - free - (47k)
128 4194304 1 freebsd-swap (2.0G)
4194432 282555023 2 freebsd-zfs (134G)
=> 63 50331585 zvol/vol01/zvol01@backup MBR (24G)
63 193 - free - (96k)
256 6291200 1 linux-data (3G)
6291456 44040192 - free - (21G)
=> 63 50331585 zvol/vol01/zvol01-clone-backup MBR (24G)
63 193 - free - (96k)
256 6291200 1 linux-data (3G)
6291456 44040192 - free - (21G)
編集＃2
Dmesgでこれらを見つけました：
ext2fs: zvol/vol01/zvol01@backup: wrong magic number 0 (expected 0xef53)
ext2fs: zvol/vol01/zvol01@backups1: wrong magic number 0 (expected 0xef53)
ext2fs: zvol/vol01/zvol01-clone-backup: wrong magic number 0 (expected 0xef53)
ext2fs: zvol/vol01/zvol01-clone-backups1: wrong magic number 0 (expected 0xef53)
ブロックデバイスがマウントされる前に、他に何かしなければならないことはありますか？
Linux VM）にエクスポートされたzvolをFreeBSDベースのFreeNASにマウントしようとしていますか？！？
もしそうなら、あなたはいくつかのことをチェックする必要があります。 zfs listとzfs get all poolname/filesystemの出力を投稿してください。
1つは、zvolのスナップショットの可視性が適切に設定されていない可能性があることです。これは、snapdevZFSプロパティを介して行われます。しかし、それはオールオアナッシングの解決策です。 zvolのスナップショットがたくさんある場合は、これを無効のままにしておくことをお勧めします。
Zvolスナップショットを使用する他のアプローチは、cloneファイルシステムです。何かのようなもの：
zfs clone vol01/zvol01@backups1 vol01/temporaryname
これにより、スナップショットに基づいて新しいzvolが作成されます。 ext2fsmountコマンドを使用してマウントできる対応するブロックデバイスが作成されます。 fdisk -lのようなものは、実際のデバイス名を表示します。
編集：
私はこれをLinuxとZFSで頻繁に行います。
zfs clone vol0/pprovol@april vol0/april # clone the zvol snapshot to new filesystem
# fdisk -l shows a new block device at /dev/zd16p1
mount -t xfs -o nouuid /dev/zd16p1 /restore # Mount filesystem using new block device
MikeyBが言ったように、パーティションを含むディスクをパーティション自体としてマウントすることはできません。ディスク内のパーティションへの直接アクセスを許可するプログラムを使用する必要があります。
私はFreeBSDにあまり精通していませんが、Linuxの場合は、
# kpartx -a /dev/zvol/vol01/zvol01-clone-backupボリュームをパーティションに分割します。パーティションは/dev/zvol/vol01/zvol01-clone-backup1
その後、そのデバイスを使用して、以前と同じようにマウントできます。
終了したら、次の手順を実行します。
# kpartx -d /dev/zvol/vol01/zvol01-clone-backupそしてあなたはあなたのまっすぐな標準のzvolに戻っています。
お役に立てば幸いです。
エラーを聞く必要があります。
パーティションテーブルのあるディスクをext2ボリュームとしてマウントしようとしています。それはうまくいきません。
256セクターのオフセットを持つzvol01をデバイスに消費するgeomデバイスを作成し、それをマウントする必要があります。
正確にそれをどのように行うか…読者の練習問題として残されています:)
また、このコンテキストでは、zfsプロモートを検索することを忘れないでください。
また、ここでのコンテキストでいくつかの利点を追加する可能性があります。
例えば。 http://www.machine-unix.com/promoting-a-zfs-file-system/
これは、従来の意味での完全なクローンを作成するのではなく、スナップショットの方向を切り替えます。
したがって、A => A @スナップショット=>スナップショット@クローン
xfs delete A @ snapshot ..エラー（依存クローンがあります）。
zfsはsnapshot @ cloneをプロモートします.。
zfs delete A @ snapshot ..エラー（それに依存するクローンがあります。snapshot@ cloneの代わりにAになりました）。
状態を簡単に切り替えることができるという意味で便利です。完全で独立したクローンを作成するには、私が考える限り、何らかの形のコピーが必要です。
（私は基本的に上記のewwhiteの投稿を少し拡張していました）。
ああ、そして参考までに、そのようなコピーを作成する例は、例えばだと思います。
zfs send -R pool/A {、snapshot} | zfsはプール/ B（またはボリュームとスナップショットの両方を複製したくない場合はAのみ）を受け取ります。
私はこれをLinuxでテストしました。