On Fri, Apr 09, 2021 at 01:07:19PM +0200, David Sterba wrote: > On Thu, Apr 08, 2021 at 05:25:28PM +0900, Naohiro Aota wrote: > > This commit moves the location of the superblock logging zones. The new > > locations of the logging zones are now determined based on fixed block > > addresses instead of on fixed zone numbers. > > > > The old placement method based on fixed zone numbers causes problems when > > one needs to inspect a file system image without access to the drive zone > > information. In such case, the super block locations cannot be reliably > > determined as the zone size is unknown. By locating the superblock logging > > zones using fixed addresses, we can scan a dumped file system image without > > the zone information since a super block copy will always be present at or > > after the fixed location. > > > > This commit introduces 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 a logging zone is outside of the disk capacity, we do not record the > > superblock copy. > > > > 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 sizes, up to 32GB. Such large zone size is > > unrealistic and very unlikely to ever be seen in real devices. Currently, > > SMR disks have a zone size of 256MB, and we are expecting ZNS drives to be > > in the 1-4GB range, so this 32GB limit gives us room to breathe. For now, > > we only allow zone sizes up to 8GB, below this hard limit of 32GB. > > > > The fixed location addresses are somewhat arbitrary, but with the intent of > > maintaining superblock reliability even for smaller devices. For this > > reason, the superblock fixed locations do not exceed 1TB. > > Yeah, so how much should we adjust the offsets in favor of smaller > devices instead of larger ones? I think this is going the wrong > direction, the capacity will grow, the zones are supposed to be larger.
For the record, we had a group discussion about that and the consensus is to do sb offsets at 0, 512G and 4T. The rationale is to prefer large devices slightly more than smaller, but are 2 superblocks available under 1T to cover small devices. Physical devices' capacity grows and the 4T copy should be available on all of the HDD type, while flash storage growth is a bit slower but still projected to be up to 10T within the time we care about now. The small devices are for usecases with not necessarily a physical device, eg. emulated or on top of device mapper targets. The superblock copy itself is not a frequently utilized feature but we still want to keep it, for parity with non-zoned mode and "just in case". I'll update the patch changelog and code to reflect the changes and resend to all people involved. The pull request is scheduled for tomorrow.
