El jue, 17 sept 2026 a las 10:33, RVP (<[email protected]>) 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.
