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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [NTFS 3]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [NTFS 3]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux