Re: rsync to ext2 filesystem issues

[Ramiro Aceves <ea1abz%gmail.com@localhost>]

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.