[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190627151100.GB20977@twin.jikos.cz>
Date: Thu, 27 Jun 2019 17:11:00 +0200
From: David Sterba <dsterba@...e.cz>
To: Naohiro Aota <Naohiro.Aota@....com>
Cc: "dsterba@...e.cz" <dsterba@...e.cz>,
"linux-btrfs@...r.kernel.org" <linux-btrfs@...r.kernel.org>,
David Sterba <dsterba@...e.com>, Chris Mason <clm@...com>,
Josef Bacik <josef@...icpanda.com>, Qu Wenruo <wqu@...e.com>,
Nikolay Borisov <nborisov@...e.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Hannes Reinecke <hare@...e.com>,
"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
Damien Le Moal <Damien.LeMoal@....com>,
Matias Bjørling <mb@...htnvm.io>,
Johannes Thumshirn <jthumshirn@...e.de>,
Bart Van Assche <bvanassche@....org>
Subject: Re: [PATCH 02/19] btrfs: Get zone information of zoned block devices
On Tue, Jun 18, 2019 at 06:42:09AM +0000, Naohiro Aota wrote:
> >> + device->seq_zones = kcalloc(BITS_TO_LONGS(device->nr_zones),
> >> + sizeof(*device->seq_zones), GFP_KERNEL);
> >
> > What's the expected range for the allocation size? There's one bit per
> > zone, so one 4KiB page can hold up to 32768 zones, with 1GiB it's 32TiB
> > of space on the drive. Ok that seems safe for now.
>
> Typically, zone size is 256MB (as default value in tcmu-runner). On such device,
> we need one 4KB page per 8TB disk space. Still it's quite safe.
Ok, and for drives up to 16T the allocation is 8kb that the allocator
usually is able to find.
> >> + u8 zone_size_shift;
> >
> > So the zone_size is always power of two? I may be missing something, but
> > I wonder if the calculations based on shifts are safe.
>
> The kernel ZBD support have a restriction that
> "The zone size must also be equal to a power of 2 number of logical blocks."
> http://zonedstorage.io/introduction/linux-support/#zbd-support-restrictions
>
> So, the zone_size is guaranteed to be power of two.
Ok. I don't remember if there are assertions, but would like to see them
in the filesystem code indpendently anyway as the mount-time sanity
checks.
Powered by blists - more mailing lists