On 11/24/20 7:46 AM, Anand Jain wrote:
On 10/11/20 7:26 pm, Naohiro Aota wrote:
Superblock (and its copies) is the only data structure in btrfs which
has a
fixed location on a device. Since we cannot overwrite in a sequential
write
required zone, we cannot place superblock in the zone. One easy
solution is
limiting superblock and copies to be placed only in conventional zones.
However, this method has two downsides: one is reduced number of
superblock
copies. The location of the second copy of superblock is 256GB, which
is in
a sequential write required zone on typical devices in the market today.
So, the number of superblock and copies is limited to be two. Second
downside is that we cannot support devices which have no conventional
zones
at all.
To solve these two problems, we employ superblock log writing. It uses
two
zones as a circular buffer to write updated superblocks. Once the first
zone is filled up, start writing into the second buffer. Then, when the
both zones are filled up and before start writing to the first zone
again,
it reset the first zone.
We can determine the position of the latest superblock by reading write
pointer information from a device. One corner case is when the both zones
are full. For this situation, we read out the last superblock of each
zone, and compare them to determine which zone is older.
The following zones are reserved as the circular buffer on ZONED btrfs.
- The primary superblock: zones 0 and 1
- The first copy: zones 16 and 17
- The second copy: zones 1024 or zone at 256GB which is minimum, and next
to it
Superblock log approach needs a non-deterministic and inconsistent
number of blocks to be read to find copy #0. And, to use 4K bytes
we are reserving a lot more space. But I don't know any better way.
I am just checking with you...
At the time of mkfs, is it possible to format the block device to
add conventional zones as needed to support our sb LBAs?
No. The number of conventional zones (if any) are a drive characteristic
and one cannot assume that the number can be modified.
OR
For superblock zones why not reset the write pointer before the
transaction commit?
A write pointer reset is equivalent to clearing the contents of the
zone, so we would lose the previous information there.
HTH.
Cheers,
Hannes
--
Dr. Hannes Reinecke Kernel Storage Architect
hare@xxxxxxx +49 911 74053 688
SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), Geschäftsführer: Felix Imendörffer
