Re: [PATCH v6 08/28] btrfs: implement log-structured superblock for HMZONED mode

[Damien Le Moal <Damien.LeMoal@wdc.com>]

Josef,

On 2019/12/14 1:39, Josef Bacik wrote:
> On 12/12/19 11:08 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 and reset the first
>> one. We can determine the postion of the latest superblock by reading write
>> pointer information from a device.
>>
>> The following zones are reserved as the circular buffer on HMZONED 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
>>
> 
> So the series of events for writing is
> 
> -> get wp
> -> write super block
> -> advance wp
>    -> if wp == end of the zone, reset the wp

In your example, the reset is for the other zone, leaving the zone that
was just filled as is. The sequence would in fact be more like this for
zones 0 & 1:

-> Get wp zone 0, if zone is full, reset it
-> write super block in zone 0
-> advance wp zone 0. If zone is full, switch to zone 1 for next update

This would come after the sequence:
-> Get wp zone 1
-> write super block in zone 1
-> advance wp zone 1. If zone is full, switch to zone 0 for next update

> 
> now assume we crash here.  We'll go to mount the fs and the zone will look like 
> it's empty because we reset the wp, and we'll be unable to mount the fs.  Am I 
> missing something here?  Thanks,

The last successful update of the super block is always present on disk
as the block right before the wp position of zone 0 or zone 1.

> 
> Josef
> 


-- 
Damien Le Moal
Western Digital Research