On Sun, 22 Nov 2020 at 16:06, Kyle Evans <kev...@freebsd.org> wrote: > > On Sun, Nov 22, 2020 at 6:00 AM Dimitry Andric <d...@freebsd.org> wrote: > > > > On 22 Nov 2020, at 08:06, Graham Perrin <grahamper...@gmail.com> wrote: > > > > > > On 20/11/2020 09:57, Graham Perrin wrote: > > >> On 16/11/2020 09:27, Graham Perrin wrote: > > >>> Attempting to build r367615 on Friday 13th: > > >>> > > >>> … > > >>> > > >>> ===> lib/libprocstat/zfs (install) > > >>> install -U -C -o root -g wheel -m 444 > > >>> /usr/src/lib/libprocstat/libprocstat.h > > >>> /usr/obj/usr/src/amd64.amd64/tmp/usr/include/ > > >>> ===> lib/libc (obj,all,install) > > >>> install -U -C -o root -g wheel -m 444 libc.a > > >>> /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/ > > >>> install -U -s -o root -g wheel -m 444 -S libc.so.7 > > >>> /usr/obj/usr/src/amd64.amd64/tmp/lib/ > > >>> install -U -o root -g wheel -m 444 libc.so.7.debug > > >>> /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/debug/lib/ > > >>> install: short write to > > >>> /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/debug/lib/libc.so.7.debug: > > >>> 393216 bytes written, 7462472 bytes asked to write > > >>> *** [_libinstall] Error code 71 > > >>> > > >>> make[4]: stopped in /usr/src/lib/libc > > >>> 1 error > > >>> > > >>> make[4]: stopped in /usr/src/lib/libc > > >>> root@mowa219-gjp4-8570p:/usr/src # > > >> > > >> The same problem – short write to > > >> /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/debug/lib/libc.so.7.debug – > > >> when attempting buildworld of r367847. > > >> > > >> If it's relevant: I'm using r367081 for these attempts. > > > > > > The same problem when attempting buildworld of r367923. Prior to this I > > > performed a fresh checkout of /usr/src > > > > > > What might cause these failures? > > > > > > If it's relevant: I have compression set to gzip-9 for the ZFS dataset > > > that mounts at /usr > > > > I'd guess it's an unintended side-effect of > > https://svnweb.freebsd.org/base?view=revision&revision=366697 > > ("install(1): Avoid unncessary fstatfs() calls and use mmap() based on > > size"). > > > > Almost certainly -- before, we would never attempt to mmap() on ZFS. > > Tossing arichardson@ into CC as the committer > Tossing mmacy@ and freqlabs@ into CC as ZFS folks > > Looking through sys/contrib/openzfs, there's special handling for mmap > on linux because it bypasses the page cache and relies on caching in > ARC. AFAICT the FreeBSD side seems to handle write() to mmap'd > regions, but doesn't do anything with VOP_MMAPPED which might be > needed to sync the file when it's mmap'd for reading like this. My > understanding of how this is supposed to actually work on FreeBSD is > limited, though, so I defer... > I'm quite surprised by this, I simply re-used the logic that bin/cp also has. However, it's possible that this is no longer used in cp due to copy_file_range? To be honest I'm not sure whether mmap() even improves performance compared to read/write since the all the MMU setup might be quite expensive and the data might not even be available so we end up copying anyway. Maybe we should change install to use read/write unconditionally? It might also make sense to factor out the copy_file_range+read/write fallback logic in bin/cp to a library that can be used in usr.bin/install.
Alex _______________________________________________ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
