Re: rsync to ext2 filesystem issues

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

El jue, 17 sept 2026 a las 10:33, RVP (<rvp%sdf.org@localhost>) escribió:
>
> On Wed, 16 Sep 2026, Ramiro Aceves wrote:
>
> > I have found this on the NetBSD page, I do not know if it is valid
> > nowadays or not:
> >
> > https://wiki.netbsd.org/tutorials/how_to_share_an_ext2_partition_with_linux/
> >
> > "The best way to share a partition with Linux is to create an EXT2
> > filesystem and use revision 0 (aka GOOD_OLD_REV) as the filesystem
> > format. By using the GOOD_OLD_REV (revision 0) format you can avoid
> > the dir_index and large_file issues encountered with DYNAMIC_REV
> > (revision 1)."
> >
>
> There's a 3GB file size limit with the revision 0 format as explained in
> newfs_ext2fs(8).
>

ohh, thanks for pointing that! I do not see it in newfs_ext2fs man
page. That is an important limitation. So I cannot use revision 0. :-(


> > [...]
> > Now,  as is, (with the filesystem crated from Linux using the
> > defaults),    I did an rsync with a clear destination directory and it
> > worked fine. I rsynced again after two days and worked but....I think
> > that the problem will arise again cause I have not changed anything.
> >
>
> Well, I conclude that the NetBSD ext2fs implementation is just buggy. As a test,
> I created a DYNAMIC_REV FS using newfs_ext2fs(8), then did your parallel copy
> test. Seemed to work fine. Unmounted and remounted; removed all the files;
> repeated again. This time, the kernel paniced in the mkdir(2) syscall inside
> ext2fs.

Ohh, good, many thanks for testing, RVP!  I see that I am not alone
and that the failure is not caused to a failing disk.

>
> If you want to keep making backups to ext2fs from NetBSD, I would avoid
> any parallel operations. :(

ok. Sorry for my ignorance, does rsync use parallel operations? If so,
how to avoid those kind of operations?


>
> > I also have found an strange thing. If I create three 1 GB file like this:
> >
> > dd if=/dev/zero of=/mnt/datos/testfile1 bs=1m count=1024
> > dd if=/dev/zero of=/mnt/datos/testfile2 bs=1m count=1024
> > dd if=/dev/zero of=/mnt/datos/testfile3 bs=1m count=1024
> >
> > I umount and mount the filesystem again.
> >
> > It turns out that the first one is read very slow using dd:
> >
> > dd if=/mnt/datos/testfile1 of=/dev/null bs=1m about 1.4 MB/s
> > dd if=/mnt/datos/testfile1 of=/dev/null bs=1m about 49 MB/s
> > dd if=/mnt/datos/testfile1 of=/dev/null bs=1m about 30 MB/s
> >
> > using filefrag (filefrag says it does not work in NetBSD) from Linux
> > shows that the first one is more fragmented than the other 2.
> >
> > # filefrag /mnt/datos/testfile1 /mnt/datos/testfile1: 24089 extents found
> > # filefrag /mnt/datos/testfile2 /mnt/datos/testfile2: 415 extents found
> > # filefrag /mnt/datos/testfile3 /mnt/datos/testfile3: 815 extents found
> >
>
> This sort-of makes sense--the more scattered the data, the more time reading'll
> take--except for the `extents' part. Only ext4 has extents as far as I'm aware.
> Maybe it's just filefrag reporting contiguous block runs as "extents"? In any
> case, ext2fs on NetBSD is just buggy...

That's is the important conclusion. Now...thinking again what
filesystem  I should use for file sharing between Linux and NetBSD...
(I never imagined how difficult this was going to be....)

Thanks.
Regards.
Ramiro.

>
> -RVP
>
> PS. one additional factor in slow read speeds relates to where the data blocks
> are placed on spinning disks. Reads from cylinders near the spindle are slow
> (easily 5 times slower reading contiguous blocks); reads from cylinders towards
> the disk edge are fastest.