Ok, it seems there is no simple method to get a list of files that are
definitely on a special vdev.
A workaround seems a simple zdb filesystem ex 'zdb tank/data | grep plain'
that gives after copying fileto the pool with small blocksize=64k and
recsize=32k:
Object lvl iblk dblk dsize dnsize lsize %full type
2 1 128K 512 0 512 512 0.00 ZFS plain file
4 1 128K 512 0 512 512 0.00 ZFS plain file
6 1 128K 512 0 512 512 0.00 ZFS plain file
256 3 128K 32K 793M 512 801M 99.47 ZFS plain file
This means the file with inode 256 is on the special vdev, a zpool list
-v gives for the special vdev c3t1d0
c3t1d0 1.88G 1.22G 674M - - 34% 64.9%
- ONLINE
when I change recsize to 128k and copy over the file again, I get (after
a file delete, otherwise recsize of zdb is incorrect)
97 3 128K 128K 407M 512 410M 99.24 ZFS plain file
This means the file with now inode 97 is now on the disk vdevs, a zpool
list -v gives for the special vdev c3t1d0
c3t1d0 1.88G 1.52G 367M - - 3% 80.9%
- ONLINE
To get a list of filenames with their inode, I use ls -ARxoli /tank/data ex
256 -rwxrwxrwx+ 1 root 840384512 Nov 12 09:43 oi.iso
If I combine ZDB and ls outputs I can get a list of files with their
onpool recsize, last edit time and size.
This will allow to select files based on a list or rules that should be
moved from the special vdev to regular vdevs or back.
Unless I miss something, this will allow a hybrid pool from disks and a
special SSD/NVMe vdev where data can be on the faster vdev either due
the physical data structure (small io, metadata, dedup data = Open-ZFS
default behaviour) or script/service based under user control for
hot/cold files based on a ruleset (classic tiering).
All new data on such a filesystem are initially declared hot
(Recsize<=SBB setting) and are in a first step stored on the special
vdev (one or more mirrors, large enough for planned use cases).
What I have seen (Is there a way to change this behaviour without a file
delete prior copy?):
If you change filesystem recsize and copy over a file from a snap, cap
usage of a special vdev via zpool list -v shows that a file is moved but
a zdb shows the new recsize setting only when you delete the file prior
the copy action that gives a new inode number for the file.
I will add a napp-it web-gui pool menu to make this comfortable.
*To long to read!*
To test filebased tiering manually:
- create a pool ex tank with a special vdev (large enough, 2/3 way
mirror when data is important, a special vdev lost is a pool lost) and a
filesystem ex tank/data
- set small block size of tank/data to 128k and recsize to 128k (this
means all new data land on the special vdev)
To store all new data to regular vdevs:
- set recsize of tank/data to a value > 128k ex 1M
To move data from regular vdevs to special vdev
- set recsize of tank/data to 128k or lower and copy over the file ex
from a snap
To move data from special vdev to regular vdevs
- set recsize of tank/data to a value > 128k and copy over the file ex
from a snap
You need a copy action, a file move does not change data location.
Have i missed something?
------------------------------------------
illumos: illumos-discuss
Permalink:
https://illumos.topicbox.com/groups/discuss/Ta9815f4d6c901308-M2ca8d0027a22428278194e02
Delivery options: https://illumos.topicbox.com/groups/discuss/subscription
