On 4/7/21 2:31 PM, Johannes Thumshirn wrote:
On 07/04/2021 19:54, Josef Bacik wrote:
On 3/15/21 1:53 AM, Naohiro Aota wrote:
This commit moves the location of superblock logging zones. The location of
the logging zones are determined based on fixed block addresses instead of
on fixed zone numbers.
By locating the superblock zones using fixed addresses, we can scan a
dumped file system image without the zone information. And, no drawbacks
exist.
We use the following three pairs of zones containing fixed offset
locations, regardless of the device zone size.
- Primary superblock: zone starting at offset 0 and the following zone
- First copy: zone containing offset 64GB and the following zone
- Second copy: zone containing offset 256GB and the following zone
If the location of the zones are outside of disk, we don't record the
superblock copy.
These addresses are arbitrary, but using addresses that are too large
reduces superblock reliability for smaller devices, so we do not want to
exceed 1T to cover all case nicely.
Also, LBAs are generally distributed initially across one head (platter
side) up to one or more zones, then go on the next head backward (the other
side of the same platter), and on to the following head/platter. Thus using
non sequential fixed addresses for superblock logging, such as 0/64G/256G,
likely result in each superblock copy being on a different head/platter
which improves chances of recovery in case of superblock read error.
These zones are reserved for superblock logging and never used for data or
metadata blocks. Zones containing the offsets used to store superblocks in
a regular btrfs volume (no zoned case) are also reserved to avoid
confusion.
Note that we only reserve the 2 zones per primary/copy actually used for
superblock logging. We don't reserve the ranges possibly containing
superblock with the largest supported zone size (0-16GB, 64G-80GB,
256G-272GB).
The first copy position is much larger than for a regular btrfs volume
(64M). This increase is to avoid overlapping with the log zones for the
primary superblock. This higher location is arbitrary but allows supporting
devices with very large zone size, up to 32GB. But we only allow zone sizes
up to 8GB for now.
Ok it took me a few reads to figure out what's going on.
The problem is that with large zone sizes, our current choices put the back up
super blocks waaaayyyyyy out on the disk, correct? So instead you've picked
arbitrary byte offsets, hoping that they'll be closer to the front of the disk
and thus actually be useful.
And then you've introduced the 8gib zone size as a way to avoid problems where
we get the same zone for the backup supers.
Are these statements correct? If so the changelog should be updated to make
this clear up front, because it took me a while to work that out.
No the problem is, we're placing superblocks into specific zones, regardless of
the zone size. This creates a problem when you need to inspect a file system,
but don't have the block device available, because you can't look at the zone
size to calculate where the superblocks are on the device.
With this change we're placing the superblocks not into specific zone numbers,
but into the zones starting at specific offsets. We're taking 8G zone size as
a maximum expected zone size, to make sure we're not overlapping superblock
zones. Currently SMR disks have a zone size of 256MB and we're expecting ZNS
drives to be in the 1-2GB range, so this 8GB gives us room to breath.
Hope this helps clearing up any confusion.
Ok this makes a lot more sense, and should be the first thing in the changelog,
because I still got it wrong after reading the thing a few times.
And I think it's worth pointing out in the comments that 8gib represents a zone
size that doesn't exist currently and is likely to never exist.
That will make this much easier to grok and understand in the future. Thanks,
Josef
