From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Mon, 8 Jan 2018 10:29:33 -0500 From: Mike Snitzer To: Christoph Hellwig Cc: Hannes Reinecke , Keith Busch , Linux Block , Linux NVMe , Device Mapper , Jens Axboe , Bart VanAssche , James Smart , "Martin K . Petersen" , Sagi Grimberg Subject: Re: [PATCH 1/5] nvme: Add more command status translation Message-ID: <20180108152933.GA9920@redhat.com> References: <20180104224623.8944-1-keith.busch@intel.com> <20180104224623.8944-2-keith.busch@intel.com> <20180108095512.GC4673@lst.de> <2beb72a9-8502-fec8-8892-208cbb0967ac@suse.com> <20180108101937.GA5423@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <20180108101937.GA5423@lst.de> List-ID: On Mon, Jan 08 2018 at 5:19am -0500, Christoph Hellwig wrote: > On Mon, Jan 08, 2018 at 11:09:03AM +0100, Hannes Reinecke wrote: > > >> case NVME_SC_SUCCESS: > > >> return BLK_STS_OK; > > >> case NVME_SC_CAP_EXCEEDED: > > >> + case NVME_SC_LBA_RANGE: > > >> return BLK_STS_NOSPC; > > > > > > lba range isn't really enospc. It is returned when the lba in > > > the command is outside the logical size of the namespace. > > > > > Isn't that distinction pretty academic? > > The entire block-to-POSIX error mapping is pretty much ad-hoc anyway... > > Yes, BLK_STS_NOSPC matters. And the fix is pretty trivial, so there is > no point in arguing. No argument needed. Definitely needs fixing. Too many upper layers consider BLK_STS_NOSPC retryable (XFS, ext4, dm-thinp, etc). Which NVME_SC_LBA_RANGE absolutely isn't. When I backfilled NVME_SC_LBA_RANGE handling I categorized it as BLK_STS_TARGET. Do you have a better suggestion for how NVME_SC_LBA_RANGE should be categorized? Mike