You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Add allocation profile export and zleak utility for import
When attempting to debug performance problems on large systems, one of
the major factors that affect performance is free space
fragmentation. This heavily affects the allocation process, which is an
area of active development in ZFS. Unfortunately, fragmenting a large
pool for testing purposes is time consuming; it usually involves filling
the pool and then repeatedly overwriting data until the free space
becomes fragmented, which can take many hours. And even if the time is
available, artificial workloads rarely generate the same fragmentation
patterns as the natural workloads they're attempting to mimic.
This patch has two parts. First, in zdb, we add the ability to export
the full allocation map of the pool. It iterates over each vdev,
printing every allocated segment in the ms_allocatable range tree. This
can be done while the pool is online, though in that case the allocation
map may actually be from several different TXGs as new ones are loaded
on demand.
The second is a new utility called zleak (and its supporting library and
kernel changes). This is a small python program that invokes a new ioctl
(via libzfs_core): zfs_ioc_raw_alloc. This ioctl takes in an nvlist of
allocations to perform, and then allocates them. It does not currently
store those allocations anywhere to make them reversible, and there is
no corresponding raw_free ioctl (which would be extremely dangerous);
this is an irreversible process, only intended for performance
testing. The only way to reclaim the space afterwards is to destroy the
pool or roll back to a checkpoint.
Signed-off-by: Paul Dagnelie <[email protected]>
Sponsored-by: Klara, Inc.
Sponsored-by: Wasabi Technology, Inc.
0 commit comments