Re: strange NVMe errors when USB is busy

Russell Coker via linux-aus <[email protected]> Sun, 26 Jan 2025 20:00:20 +1100
Newsgroups gmane.linux.australia
Message-ID <115861070.nniJfEyVGO@cupcakke>
On Sunday, 26 January 2025 19:03:14 AEDT James Cameron via linux-aus wrote:
> On Sun, Jan 26, 2025 at 05:47:33PM +1100, Russell Coker wrote:
> > On Sunday, 26 January 2025 14:51:47 AEDT James Cameron wrote:
> > > My initial response would be to reproduce and try later kernels.
> > 
> > It keeps happening on the current system, wiping 2 more disks now
> > and getting the same result.
> 
> Wiping disks is usually lots of dirty buffers and a slow dequeue of
> write I/O to the target.  free(1) and /proc/meminfo may illustrate the
> effect.  You might try the nocache package, or dd with conv=nocache.

Thanks for the suggestion, I'll try that for other reasons.  But I don't think 
that this will impact NVMe errors.  The system has 40G of write buffers in use 
which shouldn't be a big deal.

> By the way, do the kernel reports of NVMe aborts show up in any way
> higher up the stack, like in user-space failures?

Jan 25 19:05:39 xev kernel: BTRFS info (device dm-0): read error corrected: 
ino 1172304 off 163995648 (dev /dev/mapper/root2 sector 2189617968)
Jan 25 19:05:39 xev kernel: BTRFS info (device dm-0): read error corrected: 
ino 1172304 off 165031936 (dev /dev/mapper/root2 sector 2189619992)
Jan 25 19:05:39 xev kernel: BTRFS info (device dm-0): read error corrected: 
ino 1172304 off 165036032 (dev /dev/mapper/root2 sector 2189620000)

BTRFS RAID-1 sees the errors and deals with them.

-- 
My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/



_______________________________________________
linux-aus mailing list
[email protected]
https://lists.linux.org.au/mailman/listinfo/linux-aus

To unsubscribe from this list, send a blank email to
linux-aus-unsubscribe-cunTk1MwBs8iFSDQTTA3OBCuuivNXqWP@public.gmane.org