Re: [LSF/MM/BPF TOPIC] Cloud storage optimizations

[Keith Busch <kbusch@kernel.org>]

On Fri, Mar 03, 2023 at 02:14:55PM -0800, Luis Chamberlain wrote:
> On Fri, Mar 03, 2023 at 03:07:55PM -0700, Keith Busch wrote:
> > On Fri, Mar 03, 2023 at 01:45:48PM -0800, Luis Chamberlain wrote:
> > > 
> > > You'd hope most of it is left to FS + MM, but I'm not yet sure that's
> > > quite it yet. Initial experimentation shows just enabling > PAGE_SIZE
> > > physical & logical block NVMe devices gets brought down to 512 bytes.
> > > That seems odd to say the least. Would changing this be an issue now?
> > 
> > I think you're talking about removing this part:
> > 
> > ---
> > diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
> > index c2730b116dc68..2c528f56c2973 100644
> > --- a/drivers/nvme/host/core.c
> > +++ b/drivers/nvme/host/core.c
> > @@ -1828,17 +1828,7 @@ static void nvme_update_disk_info(struct gendisk *disk,
> >  	unsigned short bs = 1 << ns->lba_shift;
> >  	u32 atomic_bs, phys_bs, io_opt = 0;
> >  
> > -	/*
> > -	 * The block layer can't support LBA sizes larger than the page size
> > -	 * yet, so catch this early and don't allow block I/O.
> > -	 */
> > -	if (ns->lba_shift > PAGE_SHIFT) {
> > -		capacity = 0;
> > -		bs = (1 << 9);
> > -	}
> > -
> >  	blk_integrity_unregister(disk);
> > -
> >  	atomic_bs = phys_bs = bs;
> 
> Yes, clearly it says *yet* so that begs the question what would be
> required?

Oh, gotcha. I'll work on a list of places it currently crashes.
 
> Also, going down to 512 seems a bit dramatic, so why not just match the
> PAGE_SIZE so 4k? Would such a comprmise for now break some stuff?

The capacity set to zero ensures it can't be used through the block stack, so
the logical block size limit is unused. 512 is just a default value. We only
bring up the handle so you can administrate it with passthrough commands.