Recent searches
Search options
@platymew@layer8.spaceGood morning!
Today, i'll learn how powerful exactly the xfs_repair utility is.
Why? Well, being to tired to admin turned out worse than being too drunk. 10 hours ago, i've changed the size of a thinly provisioned #ZFS zvol from 100T to 2T, and back. Guess what's inside that zvol - exactly, an #XFS, beneath a dm-crypt layer for good measure.
Alas, my most recent snapshot is 2 weeks old. 
Yeah, setting up automatic snapshots just got bumped up to top priority - hourly, daily, weekly! 
Before going to bed, i booted the corrupted VM into #PartedMagic. xfs_repair has been printing dots ever since. I guess walking ~750 gix takes a while on a 4c/4t i3-9100F.
EDIT: it didn't finish when i woke up, so i aborted it. See thread below to learn what happened next.
Letting xfs_repair walk a 100 TB thinly provisioned volume at ~600MB/s will take about 2 days.
I've zfs send & recv replicated the corrupted volume, rolled back the corruption on the original and put it back into service, albeit with stale data.
Now, i've cloned the VM config, and pointed its storage to the corrupted zvol. Kinda neat, that #Ubuntu includes xfs_repair in their initramfs - this time, i'll let it print dots as long as it needs to. We'll see what it does, in 2 days.
I'll overprovision my VM storage in a more reasonable manner, by ~100 GB or so. About every filesystem, including XFS, can be grown to fit a lager volume - dm-crypt volumes, as well.
Kinda hilarious that i've provisioned 100 TB on a 10 TB ZFS mirror - because i could.