How to read a block in a storage pool (zpool) using dd?

I want to read开发者_开发百科 a block in zpool storage pool using dd command. Since zpool doesn't create a device file like other volume manager like vxvm. I dunno which block device to use for reading. Is there any way to read block by block data in zpool ?

You can probably use the zdb command. Here is a pdf about it, and the help output.

http://www.bruningsystems.com/osdevcon_draft3.pdf

# zdb --help

zdb: illegal option -- -
Usage: zdb [-CumdibcsDvhL] poolname [object...]
   zdb [-div] dataset [object...]
   zdb -m [-L] poolname [vdev [metaslab...]]
   zdb -R poolname vdev:offset:size[:flags]
   zdb -S poolname
   zdb -l [-u] device
   zdb -C

Dataset name must include at least one separator character '/' or '@'
If dataset name is specified, only that dataset is dumped
If object numbers are specified, only those objects are dumped

Options to control amount of output:
    -u uberblock
    -d dataset(s)
    -i intent logs
    -C config (or cachefile if alone)
    -h pool history
    -b block statistics
    -m metaslabs
    -c checksum all metadata (twice for all data) blocks
    -s report stats on zdb's I/O
    -D dedup statistics
    -S simulate dedup to measure effect
    -v verbose (applies to all others)
    -l dump label contents
    -L disable leak tracking (do not load spacemaps)
    -R read and display block from a device

Below options are intended for use with other options (except -l):
    -A ignore assertions (-A), enable panic recovery (-AA) or both (-AAA)
    -F attempt automatic rewind within safe range of transaction groups
    -U <cachefile_path> -- use alternate cachefile
    -X attempt extreme rewind (does not work with dataset)
    -e pool is exported/destroyed/has altroot/not in a cachefile
    -p <path> -- use one or more with -e to specify path to vdev dir
    -P print numbers parsable
    -t <txg> -- highest txg to use when searching for uberblocks
Specify an option more than once (e.g. -bb) to make only that option verbose
Default is to dump everything non-verbosely

Unfortunately, I don't know how to use it.

# zdb
tank:
    version: 28
    name: 'tank'
    ...
    vdev_tree:
    ...
    children[0]:
    ...
        children[0]:
    ...
            path: '/dev/label/bank1d1'
            phys_path: '/dev/label/bank1d1'

    ...

So I took the array indexes 0 0 to get my first disk (bank1d1) and did this command. It did something. I don't know how to read the output.

zdb -R tank 0:0:4e00:200 | strings

Have fun... try not to destroy anything. Here is your warning from the man page:

The  zdb  command is used by support engineers to diagnose failures and
gather statistics. Since the ZFS file system is  always  consistent  on
disk  and is self-repairing, zdb should only be run under the direction
by a support engineer.

And please tell us what you actually were looking for. Was Alan right that you wanted to do backups?

You can read from underlying raw devices in the pool, but as far as I can tell there's no concept of single contiguous block device representing the whole pool. The pool in ZFS is not a single contiguous block of sectors that 'classic' volume managers are. ZFS internal structure is closer to a tree which would be somewhat challenging to represent as a flat array of blocks.

Ben Rockwood's blog post "zdb: Examining ZFS At Point-Blank Range" may help getting better idea of what's under the hood.

No idea about what might be useful doing so but you certainly can read blocks in the underlying devices used by the pool. They are shown by the zpool status command. If you are really asking about zvols instead of zpools, they are accessible under /dev/zvol/rdsk/pool-name/zvol-name. If you want to look at internal zpool data, you probably want to use zdb.

If you want to backup ZFS filesystems you should be using the following tools:

• 'zfs snapshot' to create a stable snapshot of the filesystem
• 'zfs send' to send a copy of the snapshot to somewhere else
• 'zfs receive' to go back from a snapshot to a filesystem.

'dd' is almost certainly not the tool you should be using. In your case you could 'zfs send' and redirect the output into a file on your other filesystem.

See chapter 7 of the ZFS administration guide for more details.