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

[Luis Chamberlain <mcgrof@kernel.org>]

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?

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?

  Luis