Re: rsync to ext2 filesystem issues

[RVP <rvp%SDF.ORG@localhost>]

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).

> [...]
> 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.

If you want to keep making backups to ext2fs from NetBSD, I would avoid
any parallel 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...

-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.