El lun, 7 sept 2026 a las 10:25, Martin Husemann (<[email protected]>) escribió: > > 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.
Hi Martin, Thanks so much for answering. > > 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. > I am happy to be able to do the tests required to solve this and find the culprit of the issue. > 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. > Oh, I only can do the tests in a USB external HDD drive. I do not have free space for more partitions in the Intel Nuc MVMe or SATA SSD drives. I have both disks fully occupied. > 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. > This happened on a USB external hard disk drive. This drive is connected to a USB HUB (Amazon HUB for 10 USB ports, if I recall correctly, I am out of home now) . Should I connect the USB hard disk directly to the USB port in the Intel Nuc to see if there is any difference? > 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. We can discard network problems, I think, as in this case network is not used at all. Waiting for instructions. Regards. Ramiro. > > Martin
