Some random though on this:
Scrub traverses the data in the pool by digging through the metadata
structure starting from the current Uberblock (state at the current
TXG), so by definition (or my guess since I didn't dig through the code
to find out what ZFS does when the scrub reached data that got unlinked
after it was startet) it should't be able to see any new writes.
Thus to implement functionality that depends on on-disk persistence
(pauseable scrub, storage for sorting read lists to do real scrub reads
linear in LBA order when that data wouldn't fit into RAM completely,
...): take the handle to the last TXG as start point for scrub, then
create a dataset to use as a cache/persistance store (which will be out
of the scope of the scrub since it isn't in the metadata tree to be
examined because it'll be created on a newer TXG, if my assumption is
correct).
Should something like this not enable persistent information (or enable
to hold all needed information through mmap'ing a volume/file as kind-of
RAM extension) about the scrub process /without/ the need of a on-disk
format change or new feature? Older systems would just see a valid
dataset ('zfs-scrub-internal-metadata' or something) so one could use a
newer ZFS to fast-scrub an old pool without the need to upgrade it (and
making it unuseable with older versions of ZFS)?
Only downside I currently see is that this would spawn an additional
dataset in the pool that could be included in case you zfs send the
whole pool -R (or similar), or confuse the admin.
Gregor
-------------------------------------------
openzfs-developer
Archives: https://www.listbox.com/member/archive/274414/=now
RSS Feed: https://www.listbox.com/member/archive/rss/274414/28015062-cce53afa
Modify Your Subscription:
https://www.listbox.com/member/?member_id=28015062&id_secret=28015062-f966d51c
Powered by Listbox: http://www.listbox.com
