El 8/9/26 a las 15:22, Greg Troxel escribió:
I would urge you to slow down and test more thoroughly, and do more comprehensive testing before posting more about it. Intermediate results that something (smallish) worked are not useful because they don't prove anything.
Hi Greg, First, I’d like to apologize for sending so many short messages sharing my findings. I was simply caught up in the excitement of the moment. I’ll try to be more mindful of this in the future. I’ve taken note of the procedure you suggested. That said, I’m not sure whether I’ll be able to draw any meaningful conclusions, as there are many variables involved and my knowledge of operating systems is fairly limited. Just last night, I tried to delete the contents of the `/mnt/datos/COPIA_NETBSD_8I7/` directory using `rm -rf /mnt/datos/COPIA_NETBSD_8I7/*`, but the `rm` command reported that several directories weren't empty and couldn't be deleted (which didn't make much sense). When I checked those directories, there were n o files inside. It was evident that there was a problem with the filesystem again.I ran `fsck.ext2` from the `pkgsrc` `e2fsprogs` package, and it found numerous filesystem errors.
You could start by using the same content that's trouble, with cp, and then you could do multiple cp in parallel to subdirs. Write a script (don't just type), and write comments about why you are making choices. This includes where the fs was created, options, and why those are valid choices. After a test run, unmount, mount on linux and fsck there.
cp in parallel lead to errors, perhaps the filesystem was previously screwed up. It is very easy to draw false conclusions from all this.
If you can get it to fail, move to having the script generate synthetic data, and get it to fail, and then you can post the script. Nobody can replicate anything you are doing now. It seems that you are testing on the same disk that's been trouble. Almost certainly, you should also be testing on a different disk, with a different computer, and keep rigorous notes about what you did, where the filesystem was created, essentially writing a blog post about your testing. It would be good to figure out how to post that someplace and do that -- the details in multiple messages are too much for the list and too hard for people to follow (e.g., I'm not really trying).
Perhaps I can test with another disk to discard hw failure. But I have older disks, slower ones, they must be formated (from Linux if we want to share the same scenario) Maybe the USB bug won't get triggered with other drives (if that's the culprit)... Argh, this is really complicated. Thanks so much and sorry again. Ramiro.
