[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 2/2] hw/block/nvme: add write uncorrectable command
From: |
Klaus Jensen |
Subject: |
Re: [PATCH 2/2] hw/block/nvme: add write uncorrectable command |
Date: |
Thu, 11 Feb 2021 18:54:29 +0100 |
On Feb 12 00:37, Keith Busch wrote:
> On Thu, Feb 11, 2021 at 09:43:05AM +0100, Klaus Jensen wrote:
> > On Feb 11 12:37, Keith Busch wrote:
> >
> > > Is there a use case with a real qemu guest wanting this?
> >
> > Like for the extended metadata case (which also does not have a lot of
> > "public" exposure, but definitely have enterprise use), our main
> > motivation here was to ease testing for compliance suites and frameworks
> > like SPDK.
>
> I'm okay with the metadata patches.
>
> > I'm honestly have no clue what so ever what a real world use
> > of Write Uncorrectable would be. It's been in the spec since 1.0, so
> > there must have been some reason, Is it just to align with SCSI WRITE
> > LONG? I'm not SCSI expert at all, but from what I can read it looks like
> > that was also intended as a feature for testing read error conditions.
>
> I don't think it's for testing purposes.
>
> If you need to send a burst of non-atomic writes (ex: writing a RAID
> stripe), a power failure can result in an inconsistent state where you
> don't know at a block level which ones have old data or new data. If you
> Write Uncorrectable first, you can never read old data, and thus have no
> "write hole".
>
> Journalling solves this better, and I'm not aware of any real
> implementation relying on uncorrectable.
Right, thanks! I'm aware of the RAID write hole issue, but I did not
consider Write Uncorrectable as a possible means to solve it.
signature.asc
Description: PGP signature
[PATCH 1/2] hw/block/nvme: add oncs device parameter, Klaus Jensen, 2021/02/10