On Mon, Jan 15, 2024 at 10:33:00PM +0000, Al Viro wrote: > On Mon, Jan 15, 2024 at 10:22:20PM +0000, Al Viro wrote: > > On Mon, Jan 15, 2024 at 11:05:51PM +0100, Bruno Haible wrote: > > > > > Whereas this partition can be mounted fine on FreeBSD, NetBSD, OpenBSD. > > > FreeBSD 11: > > > # mount -r -t ufs /dev/ada1s2 /mnt > > > NetBSD 9.3: > > > # mount -r -t ffs /dev/wd1a /mnt > > > OpenBSD 7.4: > > > # mount -r -t ffs /dev/wd1j /mnt > > > > > > The source code line which emits the > > > ufs: ufs_fill_super(): fragment size 8192 is too large > > > error is obviously linux/fs/ufs/super.c:1083. > > > > Lovely... Does it really have 8Kb fragments? That would be painful > > to deal with - a plenty of places in there assume that fragment fits > > into a page... Wouldn't surprise me if netbsd/arm64 had decided to go with 64kB PAGE_SIZE and 8kB fragments ... > FWIW, theoretically it might be possible to make that comparison with > PAGE_SIZE instead of 4096 and require 16K or 64K pages for the kernel > in question; that ought to work, modulo bugs in completely untested > cases ;-/ > > Support with 4K pages is a different story - that would take much > more surgery in fs/ufs. Possibly not too much more. With large folios, we're most of the way to being able to support this. If there's real interest, we can look at supporting large folios in UFS.
