Re: possible regression fs corruption on 64GB nvme

[Robert Beckett <bob.beckett@collabora.com>]

 ---- On Wed, 11 Sep 2024 18:08:50 +0100  Keith Busch  wrote --- 
 > On Wed, Sep 11, 2024 at 05:56:37PM +0100, Robert Beckett wrote:
 > > 
 > > given this ~9 year old temporary fix is still in the kernel for the
 > > Apple device, could we just add another device specific override? I
 > > could maybe convert it to a quirk that is set for them both (and any
 > > future devices)
 > 
 > Sure, that's an option. Do you want to send a patch? Alternatively you
 > can reply with the PCI VID:DID of your problematic device and I'll write
 > one for testing and consideration.

looks like it's 1217:8760

01:00.0 Non-Volatile memory controller [0108]: O2 Micro, Inc. Device [1217:8760] (rev 01) (prog-if 02 [NVM Express])
        Subsystem: O2 Micro, Inc. Device [1217:0002]
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0, Cache Line Size: 64 bytes
        Interrupt: pin A routed to IRQ 41
        Region 0: Memory at 80600000 (64-bit, non-prefetchable) [size=16K]
        Capabilities: <access denied>
        Kernel driver in use: nvme
        Kernel modules: nvme

 > 
 > And just fyi, there are potential performance implications for doing
 > this. It's less noticable on higher latency devices, which sounds like
 > what you have anyway, so may not matter much for you. Just getting that
 > out there to avoid any surprises.

Understood. I'll do some benchmarking with and without it to check difference.
I think for now it is safer to get it in the code as it can cause corruption. We can always revert it if we figure out a fix with less performance degredation.

Cheers muchly!