While it is possible that the ext2 file system implementation in NetBSD has bugs, it is also possible that the underlying hardware driver has trouble.
The ext2 code is exercised by the regular ATF tests, so part of all automtic test runs that we do - however, those are not on bare metall with full speed and high IO load. So separating hardware driver/IO load and ext2 bugs would be a first step. If you could reproduce the problem with rsync from/to a ext2 filesystem on a regulard disk (or SSD) say on an ahcisata connected disk or NVMe ld device that would be a big pointer at issues in the file system code and time to file a PR with reproduction instructions. If this originally happened on a USB disk, we need more info (like full dmesg) and probably you want to enable USB debugging and check that once it stalls. On a USB disk you should be able trigger the same effect with some random file system performance test. A third issue could be that rsync has networking trouble (like lost packets repeated forever due to network interface bugs or some misconfiguration). To exclude this, doing the rsync tests locally would be a good idea. Martin
