NetBSD-Bugs archive

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

Re: kern/55674: ld(4) should attempt to allocate ld(4) for 0 size disks



The following reply was made to PR kern/55674; it has been noted by GNATS.

From: Frank Kardel <kardel%netbsd.org@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: kern/55674: ld(4) should attempt to allocate ld(4) for 0 size
 disks
Date: Mon, 21 Sep 2020 14:02:07 +0200

 Yepp - the data size = 1 comes from the blind 1 << lbads(==0) expression 
 (nvmectl). lbads == 0 means not available.
 
 ld_attach() attempts to bail out on this condition, which is, as I 
 agree, too late.
 
 We should fix nvme_rescan() in ic/nvme.c to do the inquiriy part and 
 initial check from
 
 ld_nvme.c:ld_nvme_attach(). Unfortunately this introduces one additional 
 inquiry per
 
 valid namespace. But that is better than to allocate 13k mostly dead 
 ld(4) instances for just 3 devices.
 
 Frank
 
 On 09/21/20 12:55, Michael van Elst wrote:
 > The following reply was made to PR kern/55674; it has been noted by GNATS.
 >
 > From: mlelstv%serpens.de@localhost (Michael van Elst)
 > To: gnats-bugs%netbsd.org@localhost
 > Cc:
 > Subject: Re: kern/55674: ld(4) should attempt to allocate ld(4) for 0 size disks
 > Date: Mon, 21 Sep 2020 10:51:59 -0000 (UTC)
 >
 >   kardel%netbsd.org@localhost (Frank Kardel) writes:
 >   
 >   >> nvmectl identify nvme0ns2
 >   >> Size (in LBAs):              0 (0M)
 >   >> Capacity (in LBAs):          0 (0M)
 >   >> Utilization (in LBAs):       0 (0M)
 >   >> Thin Provisioning:           Not Supported
 >   >> Number of LBA Formats:       1
 >   >> Current LBA Format:          LBA Format #00
 >   >> LBA Format #00: Data Size:     1  Metadata Size:     0
 >   
 >   A size of zero is perfectly valid, but a "data size" of 1 (byte per block)
 >   is invalid.
 >   
 >   The ld(4) attachment already fails with that data size, but since this
 >   happens within the attach routine that cannot signal failure, the ld(4)
 >   units are still created.
 >   
 >   A workaround would be to issue the identify command and check the format
 >   already in the nvme driver. As long as ld(4) is the only child for nvme
 >   this shouldn't cause any problems.
 >   
 >   --
 >   --
 >                                   Michael van Elst
 >   Internet: mlelstv%serpens.de@localhost
 >                                   "A potential Snark may lurk in every tree."
 >   
 


Home | Main Index | Thread Index | Old Index