Re: Dell Latitude 7400 - nvme0: Missing interrupt
On Sun, Oct 10, 2021 at 10:48 PM Pavel Timofeev wrote: > сб, 9 окт. 2021 г. в 14:59, Warner Losh : > >> >> >> On Sat, Oct 9, 2021, 8:44 AM Pavel Timofeev wrote: >> >>> >>> >>> пт, 8 окт. 2021 г. в 14:49, Warner Losh : >>> On Fri, Oct 8, 2021 at 2:42 PM Pavel Timofeev wrote: > > > сб, 21 авг. 2021 г. в 15:22, Warner Losh : > >> >> >> On Sat, Aug 21, 2021 at 3:06 PM Pavel Timofeev >> wrote: >> >>> >>> >>> Warner Losh : >>> On Fri, Aug 20, 2021 at 10:42 PM Pavel Timofeev wrote: > Pavel Timofeev : > > > > > Chuck Tuffli : > > > >> On Mon, Aug 16, 2021 at 7:43 PM Pavel Timofeev < > tim...@gmail.com> wrote: > >> > > >> > Hello > >> > I've got a Dell Latitude 7400 and tried installing the latest > >> 14.0-CURRENT > >> > (main-n248636-d20e9e02db3) on it. > >> > Despite other things the weird one which concerns me is > >> > nvme0: Missing interrupt > >> > message I get sometimes on the console. > >> > It seems like I get it only after the reboot of the laptop, > i. e. not > >> > getting that message if I power cycle the laptop, at least I > haven't > >> seen > >> > them for now in such cases. > >> > So when the laptop is rebooted I can't even take advantage of > >> > nvmecontrol(8) quickly. > >> > Well, it still works, but it takes tens of seconds to return > the output. > >> ... > >> > dmesg when power cycled - > >> > > https://drive.google.com/file/d/1dB27oB1O2CcnZy6DvOOhmFO8SN8V8SwJ > >> > dmesg when rebooted - > >> > > https://drive.google.com/file/d/1DsKTMkihp_OmUcirByLaVO4o2mU38Bxh > >> > >> I'm sort of curious about the time stamps for the log messages > in the > >> failing case. Something like: > >> > >> $ grep "nv\(me\|d\)" /var/log/messages > >> > >> --chuck > >> > > > > Well, I can't see timestamps in the verbose boot log. Am I > missing some > > configuration for that? > > > > $ grep "nv\(me\|d\)" /var/log/messages > > nvme0: mem > > > 0xcc10-0xcc103fff,0xcc105000-0xcc105fff,0xcc104000-0xcc104fff at > device > > 0.0 on pci6 > > nvme0: attempting to allocate 5 MSI-X vectors (17 supported) > > nvme0: using IRQs 133-137 for MSI-X > > nvme0: CapLo: 0x140103ff: MQES 1023, CQR, TO 20 > > nvme0: CapHi: 0x0030: DSTRD 0, NSSRS, CSS 1, MPSMIN 0, > MPSMAX 0 > > nvme0: Version: 0x00010300: 1.3 > > nvme0: Missing interrupt > > nvme0: Missing interrupt > > nvme0: Missing interrupt > > nvme0: Missing interrupt > > nvme0: Missing interrupt > > nvme0: Missing interrupt > > nvme0: Missing interrupt > > nvme0: Missing interrupt > > nvme0: Missing interrupt > > nvme0: Missing interrupt > > nvme0: Missing interrupt > > nvme0: Missing interrupt > > nvd0: NVMe namespace > > GEOM: new disk nvd0 > > nvd0: 488386MB (1000215216 512 byte sectors) > > > > > Ah, sorry, provided wrong output. > Here is what you requested: > $ grep "nv\(me\|d\)" /var/log/messages > Aug 21 04:34:36 nostromo kernel: nvme0: mem > 0xcc10-0xcc103fff,0xcc105000-0xcc105fff,0xcc104000-0xcc104fff > at device > 0.0 on pci6 > Aug 21 04:34:36 nostromo kernel: nvme0: attempting to allocate 5 > MSI-X > vectors (17 supported) > Aug 21 04:34:36 nostromo kernel: nvme0: using IRQs 133-137 for > MSI-X > Aug 21 04:34:36 nostromo kernel: nvme0: CapLo: 0x140103ff: MQES > 1023, CQR, > TO 20 > Aug 21 04:34:36 nostromo kernel: nvme0: CapHi: 0x0030: DSTRD > 0, NSSRS, > CSS 1, MPSMIN 0, MPSMAX 0 > Aug 21 04:34:36 nostromo kernel: nvme0: Version: 0x00010300: 1.3 > Aug 21 04:34:36 nostromo kernel: nvme0: Missing interrupt > Aug 21 04:34:36 nostromo kernel: nvme0: Missing interrupt > Aug 21 04:34:36 nostromo kernel: nvme0: Missing interrupt > Aug 21 04:34:36 nostromo kernel: nvd0: > NVMe > namespace > Aug 21 04:34:36 nostromo kernel: GEOM: new disk nvd0 > Aug 21 04:34:36 nostromo kernel: nvd0: 488386MB (1000215216 512 > byte > sectors) > Aug 21 04:34:42 nostromo kernel: nvme0: Missing interrupt > Aug 21 04:35:36 nostromo kernel: nvme0: Missing interrupt > Aug 21 04:35:50 nostromo kernel: nvme0: Missing interrupt > What happens if you set hw.nvme.use_nvd=0 and
Re: Dell Latitude 7400 - nvme0: Missing interrupt
сб, 9 окт. 2021 г. в 14:59, Warner Losh : > > > On Sat, Oct 9, 2021, 8:44 AM Pavel Timofeev wrote: > >> >> >> пт, 8 окт. 2021 г. в 14:49, Warner Losh : >> >>> >>> >>> On Fri, Oct 8, 2021 at 2:42 PM Pavel Timofeev wrote: >>> сб, 21 авг. 2021 г. в 15:22, Warner Losh : > > > On Sat, Aug 21, 2021 at 3:06 PM Pavel Timofeev > wrote: > >> >> >> Warner Losh : >> >>> >>> >>> On Fri, Aug 20, 2021 at 10:42 PM Pavel Timofeev >>> wrote: >>> Pavel Timofeev : > > Chuck Tuffli : > >> On Mon, Aug 16, 2021 at 7:43 PM Pavel Timofeev wrote: >> > >> > Hello >> > I've got a Dell Latitude 7400 and tried installing the latest >> 14.0-CURRENT >> > (main-n248636-d20e9e02db3) on it. >> > Despite other things the weird one which concerns me is >> > nvme0: Missing interrupt >> > message I get sometimes on the console. >> > It seems like I get it only after the reboot of the laptop, i. e. not >> > getting that message if I power cycle the laptop, at least I haven't >> seen >> > them for now in such cases. >> > So when the laptop is rebooted I can't even take advantage of >> > nvmecontrol(8) quickly. >> > Well, it still works, but it takes tens of seconds to return the output. >> ... >> > dmesg when power cycled - >> > https://drive.google.com/file/d/1dB27oB1O2CcnZy6DvOOhmFO8SN8V8SwJ >> > dmesg when rebooted - >> > https://drive.google.com/file/d/1DsKTMkihp_OmUcirByLaVO4o2mU38Bxh >> >> I'm sort of curious about the time stamps for the log messages in the >> failing case. Something like: >> >> $ grep "nv\(me\|d\)" /var/log/messages >> >> --chuck >> > > Well, I can't see timestamps in the verbose boot log. Am I missing some > configuration for that? > > $ grep "nv\(me\|d\)" /var/log/messages > nvme0: mem > 0xcc10-0xcc103fff,0xcc105000-0xcc105fff,0xcc104000-0xcc104fff at device > 0.0 on pci6 > nvme0: attempting to allocate 5 MSI-X vectors (17 supported) > nvme0: using IRQs 133-137 for MSI-X > nvme0: CapLo: 0x140103ff: MQES 1023, CQR, TO 20 > nvme0: CapHi: 0x0030: DSTRD 0, NSSRS, CSS 1, MPSMIN 0, MPSMAX 0 > nvme0: Version: 0x00010300: 1.3 > nvme0: Missing interrupt > nvme0: Missing interrupt > nvme0: Missing interrupt > nvme0: Missing interrupt > nvme0: Missing interrupt > nvme0: Missing interrupt > nvme0: Missing interrupt > nvme0: Missing interrupt > nvme0: Missing interrupt > nvme0: Missing interrupt > nvme0: Missing interrupt > nvme0: Missing interrupt > nvd0: NVMe namespace > GEOM: new disk nvd0 > nvd0: 488386MB (1000215216 512 byte sectors) > Ah, sorry, provided wrong output. Here is what you requested: $ grep "nv\(me\|d\)" /var/log/messages Aug 21 04:34:36 nostromo kernel: nvme0: mem 0xcc10-0xcc103fff,0xcc105000-0xcc105fff,0xcc104000-0xcc104fff at device 0.0 on pci6 Aug 21 04:34:36 nostromo kernel: nvme0: attempting to allocate 5 MSI-X vectors (17 supported) Aug 21 04:34:36 nostromo kernel: nvme0: using IRQs 133-137 for MSI-X Aug 21 04:34:36 nostromo kernel: nvme0: CapLo: 0x140103ff: MQES 1023, CQR, TO 20 Aug 21 04:34:36 nostromo kernel: nvme0: CapHi: 0x0030: DSTRD 0, NSSRS, CSS 1, MPSMIN 0, MPSMAX 0 Aug 21 04:34:36 nostromo kernel: nvme0: Version: 0x00010300: 1.3 Aug 21 04:34:36 nostromo kernel: nvme0: Missing interrupt Aug 21 04:34:36 nostromo kernel: nvme0: Missing interrupt Aug 21 04:34:36 nostromo kernel: nvme0: Missing interrupt Aug 21 04:34:36 nostromo kernel: nvd0: NVMe namespace Aug 21 04:34:36 nostromo kernel: GEOM: new disk nvd0 Aug 21 04:34:36 nostromo kernel: nvd0: 488386MB (1000215216 512 byte sectors) Aug 21 04:34:42 nostromo kernel: nvme0: Missing interrupt Aug 21 04:35:36 nostromo kernel: nvme0: Missing interrupt Aug 21 04:35:50 nostromo kernel: nvme0: Missing interrupt >>> >>> What happens if you set hw.nvme.use_nvd=0 and hw.cam.nda.nvd_compat=1 >>> in the boot loader and reboot? Same thing except nda where nvd was? >>> Or does >>> it work? >>> >>> Something weird is going on in the interrupt assignment, I think, >>> but I >>> wanted to get
Re: clang/llvm-tblgen --- ld: error: undefined symbol: setupterm
On Sun, 10 Oct 2021 at 22:17, Baptiste Daroussin wrote: > > > > > I don't know if this is the right place to jump in, but I suspect this > > is a related issue? > > I'm trying to do the opposite - building 14 on a 13-STABLE machine. It > > fails when trying to build ncurses: > > > > root@p14s-bsd:/usr/src # uname -v > > FreeBSD 13.0-STABLE #0 stable/13-n247584-fdbbd118faa: Sun Oct 10 > > 03:25:38 CEST 2021 > > root@p14s-bsd:/usr/obj/usr/src/amd64.amd64/sys/GENERIC > > root@p14s-bsd:/usr/src # git pull > > Already up to date. > > root@p14s-bsd:/usr/src # git status > > On branch main > > Your branch is up to date with 'origin/main'. > > > > nothing to commit, working tree clean > > root@p14s-bsd:/usr/src # make buildworld > build.log > > (...) > > > > The full log is at http://eurostar.nebdal.no/build.log > > It's all variations over this: > > > > ===> lib/ncurses/ncurses (obj,all,install) > > Building /usr/obj/usr/src/amd64.amd64/lib/ncurses/ncurses/lib_color.o > > /usr/src/contrib/ncurses/ncurses/base/lib_color.c:192:5: error: > > implicit declaration of function '_nc_tiparm' is invalid in C99 > > [-Werror,-Wimplicit-function-declaration] > > TIPARM_1(set_a_background, bg), > > ^ > > /usr/src/contrib/ncurses/include/nc_tparm.h:81:23: note: expanded from > > macro 'TIPARM_1' > > #define TIPARM_1(s,a) _nc_tiparm(1,s,a) > > ^ > > /usr/src/contrib/ncurses/ncurses/base/lib_color.c:192:5: error: > > incompatible integer to pointer conversion passing 'int' to parameter > > of type 'const char *' [-Werror,-Wint-conversion] > > TIPARM_1(set_a_background, bg), > > ^~ > > /usr/src/contrib/ncurses/include/nc_tparm.h:81:23: note: expanded from > > macro 'TIPARM_1' > > #define TIPARM_1(s,a) _nc_tiparm(1,s,a) > > ^ > > > > -DanielN > > It is an entirely different storry that deserves its own investigation! > > I will try to find time in the next couple of days. > > In the meantile could you provide your make.conf, src.conf and src-env.conf? > > Best regards > Bapt Sure - they're plain enough: # cat /etc/make.conf cat: /etc/make.conf: No such file or directory # cat /etc/src.conf cat: /etc/src.conf: No such file or directory # cat /etc/src-env.conf WITH_META_MODE=YES I did try with meta mode disabled as well, with the same result. -DanielN
Re: clang/llvm-tblgen --- ld: error: undefined symbol: setupterm
10 oct. 2021 16:43:52 Daniel Nebdal : > On Sun, 10 Oct 2021 at 07:46, Baptiste Daroussin wrote: >> >> On Sat, Oct 09, 2021 at 11:33:54PM -0600, Warner Losh wrote: >>> On Sat, Oct 9, 2021 at 11:29 PM Kyle Evans wrote: >>> On Sun, Oct 10, 2021 at 12:18 AM Warner Losh wrote: > > On Sat, Oct 9, 2021 at 10:45 PM Warner Losh wrote: > >> … d...@freebsd.org> >> … wrote: >> … > >> … the >> … since >> … /pool/home/ohartmann/Projects/router/router/apu2c4/src/tools/install.sh >> … c4/world/amd64/ALERICH_13-STABLE_amd64/pool/home/ohartmann/Projects/router/router/apu2c4/src/amd64.amd64/tmp/legacy/usr/bin/compile_et >> … ld: >> … Process.o:(llvm::sys::Process::FileDescriptorHasColors(int)) >> … that >> … to >> … got >> … suitable >> … in >> … functions >> … return >> … OK; } >> … might >> … to >> … not >> … messages >> … protecting >> … disabled >> … for a >> … the >> … the >> … first >> … be to >> … probably we >> … having >> … but >> … > > Though it's still a 'patch the past' path forward... The fix is trivial to > describe. > It doesn't sound like there's any need to 'patch the past'... the status quo is that the static libncursesw is effectively "broken" because consumers need to know to link to libtinfow. If the linker script idea works (which it seems like it will) then it's a non-issue; either we're building on a system that has the all-in-one libncursesw or we're building against a linker script that also does the right thing. >>> >>> Yea, the linker script notion is the only thing that's talked about so >>> far that's something where we don't need to patch the past. The >>> old tools know how to cope with the linker script and will bring the >>> right things in. My comments were about removing -DNO_SHARED... >>> >>> We should remove -DNO_SHARED as well from the bootstrap tools, >>> but that's a separate issue if the linker script works. >>> >>> Warner >> >> This https://reviews.freebsd.org/D32435 should make freebsd stable 12 and 13 >> buildable out of box again on freebsd 14. >> >> Best regards, >> Bapt >> > > I don't know if this is the right place to jump in, but I suspect this > is a related issue? > I'm trying to do the opposite - building 14 on a 13-STABLE machine. It > fails when trying to build ncurses: > > root@p14s-bsd:/usr/src # uname -v > FreeBSD 13.0-STABLE #0 stable/13-n247584-fdbbd118faa: Sun Oct 10 > 03:25:38 CEST 2021 > root@p14s-bsd:/usr/obj/usr/src/amd64.amd64/sys/GENERIC > root@p14s-bsd:/usr/src # git pull > Already up to date. > root@p14s-bsd:/usr/src # git status > On branch main > Your branch is up to date with 'origin/main'. > > nothing to commit, working tree clean > root@p14s-bsd:/usr/src # make buildworld > build.log > (...) > > The full log is at http://eurostar.nebdal.no/build.log > It's all variations over this: > > ===> lib/ncurses/ncurses (obj,all,install) > Building /usr/obj/usr/src/amd64.amd64/lib/ncurses/ncurses/lib_color.o > /usr/src/contrib/ncurses/ncurses/base/lib_color.c:192:5: error: > implicit declaration of function '_nc_tiparm' is invalid in C99 > [-Werror,-Wimplicit-function-declaration] > TIPARM_1(set_a_background, bg), > ^ > /usr/src/contrib/ncurses/include/nc_tparm.h:81:23: note: expanded from > macro 'TIPARM_1' > #define TIPARM_1(s,a) _nc_tiparm(1,s,a) > ^ > /usr/src/contrib/ncurses/ncurses/base/lib_color.c:192:5: error: > incompatible integer to pointer conversion passing 'int' to parameter > of type 'const char *' [-Werror,-Wint-conversion] > TIPARM_1(set_a_background, bg), > ^~ > /usr/src/contrib/ncurses/include/nc_tparm.h:81:23: note: expanded from > macro 'TIPARM_1' > #define TIPARM_1(s,a) _nc_tiparm(1,s,a) > ^ > > -DanielN It is an entirely different storry that deserves its own investigation! I will try to find time in the next couple of days. In the meantile could you provide your make.conf, src.conf and src-env.conf? Best regards Bapt
Re: RFC: Use of VOP_ALLOCATE() by NFSV4.2 nfsd
On 10-10-2021 07:57, Rick Macklem wrote: This leads me to a couple of questions: - Is there a good reason for not using vop_stdallocate() for ZFS? Yes. posix_fallocate is supposed to guarantee that subsequent writes to the file will not fail with ENOSPC. But ZFS, being a copy-on-write file system, cannot possibly guarantee that. See SVN r325320. However, vop_stdallocate() just does VOP_WRITE()s to the area (with bytes of data all zeros). Wouldn't that satisfy the criteria? I had the same problem in Ceph, where a guaranteed writable space is required for keeping a log of modifications to the system. Not having this space might case loss of data. Writing al zero's is probably even worse on filesystems that have compression set. Almost nothing is allocated, and so no guarantee at all. Next trick wass to write random data, but then you run into the problem signaled by Alan and Warner. New writes will need free space, since the CoW nature. Solution was to actually create a specific zpool just for this. But that will not help you with NFS 4.2 I guess --WjW
Re: clang/llvm-tblgen --- ld: error: undefined symbol: setupterm
On Sun, 10 Oct 2021 at 07:46, Baptiste Daroussin wrote:
>
> On Sat, Oct 09, 2021 at 11:33:54PM -0600, Warner Losh wrote:
> > On Sat, Oct 9, 2021 at 11:29 PM Kyle Evans wrote:
> >
> > > On Sun, Oct 10, 2021 at 12:18 AM Warner Losh wrote:
> > > >
> > > > On Sat, Oct 9, 2021 at 10:45 PM Warner Losh wrote:
> > > >
> > > > >
> > > > >
> > > > > On Sat, Oct 9, 2021 at 10:41 PM Baptiste Daroussin
> > > > > wrote:
> > > > >
> > > > >> On Sun, Oct 10, 2021 at 06:06:37AM +0200, Baptiste Daroussin wrote:
> > > > >> > On Sun, Oct 10, 2021 at 02:52:58AM +0300, Konstantin Belousov
> > > > >> > wrote:
> > > > >> > > On Sat, Oct 09, 2021 at 05:29:39PM -0600, Warner Losh wrote:
> > > > >> > > > On Sat, Oct 9, 2021, 5:15 PM Konstantin Belousov <
> > > > >> kostik...@gmail.com>
> > > > >> > > > wrote:
> > > > >> > > >
> > > > >> > > > > On Sat, Oct 09, 2021 at 04:47:35PM -0600, Warner Losh wrote:
> > > > >> > > > > > On Sat, Oct 9, 2021 at 11:09 AM Dimitry Andric <
> > > d...@freebsd.org>
> > > > >> wrote:
> > > > >> > > > > >
> > > > >> > > > > > > On 9 Oct 2021, at 15:40, Warner Losh
> > > wrote:
> > > > >> > > > > > > >
> > > > >> > > > > > > > On Sat, Oct 9, 2021, 5:59 AM Dimitry Andric <
> > > > >> d...@freebsd.org> wrote:
> > > > >> > > > > > > > On 9 Oct 2021, at 13:37, Dimitry Andric
> > > > >> > > > > > > > > > >
> > > > >> wrote:
> > > > >> > > > > > > > >
> > > > >> > > > > > > > > On 9 Oct 2021, at 09:46, FreeBSD User <
> > > > >> free...@walstatt-de.de>
> > > > >> > > > > wrote:
> > > > >> > > > > > > > >>
> > > > >> > > > > > > > >> On recent CURRENT (FreeBSD 14.0-CURRENT #2
> > > > >> > > > > main-n249971-0525ece3554e:
> > > > >> > > > > > > > >> Fri Oct 8 15:17:34 CEST 2021 amd64) building of an
> > > > >> 13-STABLE
> > > > >> > > > > based
> > > > >> > > > > > > > >> appliance failed very early in the build process of
> > > the
> > > > >> 13-STABLE
> > > > >> > > > > > > > >> sources as shown below. 13-STABLE is most recent,
> > > since
> > > > >> the
> > > > >> > > > > sources
> > > > >> > > > > > > are
> > > > >> > > > > > > > >> fetched every time the build process is triggered.
> > > > >> > > > > > > > > ...
> > > > >> > > > > > > > >>
> > > > >> > > > > > >
> > > > >>
> > > /pool/home/ohartmann/Projects/router/router/apu2c4/src/tools/install.sh
> > > > >> > > > > > > > >> -s -o root -g wheel -m 555 compile_et
> > > > >> > > > > > > > >> /pool/home/ohartmann/Projects/router/router/apu2
> > > > >> > > > > > > > >>
> > > > >> > > > > > >
> > > > >> > > > >
> > > > >>
> > > c4/world/amd64/ALERICH_13-STABLE_amd64/pool/home/ohartmann/Projects/router/router/apu2c4/src/amd64.amd64/tmp/legacy/usr/bin/compile_et
> > > > >> > > > > > > > >> --- _bootstrap-tools-usr.bin/clang/llvm-tblgen ---
> > > ld:
> > > > >> error:
> > > > >> > > > > > > undefined
> > > > >> > > > > > > > >> symbol: setupterm
> > > > >> > > > > > > > > referenced by Process.cpp
> > > > >> > > > > > > > >
> > > > >> > > > > > >
> > > Process.o:(llvm::sys::Process::FileDescriptorHasColors(int))
> > > > >> > > > > > > > >
> > > > >> > > > > > > > > It is complaining about ncurses functions; it seems
> > > that
> > > > >> even
> > > > >> > > > > though
> > > > >> > > > > > > the link step gets -lncursesw added, it still is not able
> > > to
> > > > >> find the
> > > > >> > > > > > > symbol:
> > > > >> > > > > > > >
> > > > >> > > > > > > > Okay, this is because recently on -CURRENT, libtinfow
> > > got
> > > > >> split off
> > > > >> > > > > from
> > > > >> > > > > > > > libncursesw:
> > > > >> https://cgit.freebsd.org/src/commit/?id=396851c20aebd
> > > > >> > > > > > > >
> > > > >> > > > > > > > This affects such cross-builds obviously, and manually
> > > > >> adding
> > > > >> > > > > -ltinfow
> > > > >> > > > > > > > to the link command line makes it link correctly.
> > > > >> > > > > > > >
> > > > >> > > > > > > > However, the 396851c20aebd commit is probably not
> > > suitable
> > > > >> for
> > > > >> > > > > MFC'ing
> > > > >> > > > > > > > to stable/13. Maybe we need to put some kind of kludge
> > > in
> > > > >> > > > > > > > share/mk/src.libnames.mk for this, or in the top-level
> > > > >> > > > > Makefile.inc1?
> > > > >> > > > > > > >
> > > > >> > > > > > > > Baptiste, any ideas? :)
> > > > >> > > > > > > >
> > > > >> > > > > > > > Add setupterm() to libegacy as a nop.
> > > > >> > > > > > >
> > > > >> > > > > > > That's not enough I think, it requires more ncurses
> > > functions
> > > > >> than just
> > > > >> > > > > > > setupterm. And it actually calls them and checks the
> > > return
> > > > >> values too,
> > > > >> > > > > > > IIRC. :)
> > > > >> > > > > > >
> > > > >> > > > > >
> > > > >> > > > > > int setupterm(const char *t, int fd, int *errptr) { return
> > > OK; }
> > > > >> > > > > > int tigetnum(const char *t) { return 0; }
> > > > >> > > > > > TERMINAL *set_curterm(TERMINAL *t) { return NULL; }
> > > > >> > > > > > int del_curterm(TERMINAL *t) { return OK; }
> > > > >> > > > > >
> > > > >> > > > > >
Re: RFC: Use of VOP_ALLOCATE() by NFSV4.2 nfsd
Alan Somers wrote: [stuff snipped] >Rick Macklem wrote: > >Alan Somers wrote: > > >Yes. posix_fallocate is supposed to guarantee that subsequent writes > > >to the file will not fail with ENOSPC. But ZFS, being a copy-on-write > > >file system, cannot possibly guarantee that. See SVN r325320. > > However, vop_stdallocate() just does VOP_WRITE()s to the area (with > > bytes of data all zeros). Wouldn't that satisfy the criteria? > > No. It works for UFS, which is an overwriting file system. But for > ZFS, when the user comes back later to rewrite those same offsets, ZFS > will actually allocate new LBAs for them. Eighto. I get it now. Looks like I must disable it in the server, unless there is a way to enable it on a per file system basis (which I don not believe is the case for NFSv4.2, although that isn't completely clear from the RFC, which says each operation is optional, but does not mention "per file system"). Thanks everyone, for your replies, rick > > >> - Should I try and support both file system types via vop_stdallocate() > >> or not support Allocate at all? > > > >Since you can't possibly support it for ZFS (not to mention other file > >systems like fusefs) you'll have to not support it at all. > It does sound like not supporting it is the best alternative. > > rick > > > > > Btw, as a bit of an aside, "cc" uses posix_fallocate() and in weird ways, > > such as offset=0, len=1. Why, I have no idea? > > > > Thanks in advance for any comments, rick > >
Re: RFC: Use of VOP_ALLOCATE() by NFSV4.2 nfsd
On Sat, Oct 9, 2021 at 11:57 PM Rick Macklem wrote: > > Alan Somers wrote: > >On Sat, Oct 9, 2021 at 7:13 PM Rick Macklem wrote: > >> > >> Hi, > >> > >> I ran into an issue this week during the nf...@ietf.org's testing event. > >> UFS - supports VOP_ALLOCATE() by using vop_stdallocate(). > >> ZFS - just return EINVAL for VOP_ALLOCATE(). > >> > >> An NFSv4.2 server can either support Allocate or not, but it has to be > >> for all exported file systems. > > > >That seems like a protocol bug to me. Could this be fixed in a future > >NFS revision? > Who knows. I don't see any interest in a 4.3. 4.2 is extensible, but I think > this is now "cast in stone". > > >> > >> This leads me to a couple of questions: > >> - Is there a good reason for not using vop_stdallocate() for ZFS? > > > >Yes. posix_fallocate is supposed to guarantee that subsequent writes > >to the file will not fail with ENOSPC. But ZFS, being a copy-on-write > >file system, cannot possibly guarantee that. See SVN r325320. > However, vop_stdallocate() just does VOP_WRITE()s to the area (with > bytes of data all zeros). Wouldn't that satisfy the criteria? No. It works for UFS, which is an overwriting file system. But for ZFS, when the user comes back later to rewrite those same offsets, ZFS will actually allocate new LBAs for them. > > >> - Should I try and support both file system types via vop_stdallocate() > >> or not support Allocate at all? > > > >Since you can't possibly support it for ZFS (not to mention other file > >systems like fusefs) you'll have to not support it at all. > It does sound like not supporting it is the best alternative. > > rick > > > > > Btw, as a bit of an aside, "cc" uses posix_fallocate() and in weird ways, > > such as offset=0, len=1. Why, I have no idea? > > > > Thanks in advance for any comments, rick > >
Re: RFC: Use of VOP_ALLOCATE() by NFSV4.2 nfsd
On Sat, Oct 9, 2021, 11:58 PM Rick Macklem wrote: > Alan Somers wrote: > >On Sat, Oct 9, 2021 at 7:13 PM Rick Macklem wrote: > >> > >> Hi, > >> > >> I ran into an issue this week during the nf...@ietf.org's testing > event. > >> UFS - supports VOP_ALLOCATE() by using vop_stdallocate(). > >> ZFS - just return EINVAL for VOP_ALLOCATE(). > >> > >> An NFSv4.2 server can either support Allocate or not, but it has to be > >> for all exported file systems. > > > >That seems like a protocol bug to me. Could this be fixed in a future > >NFS revision? > Who knows. I don't see any interest in a 4.3. 4.2 is extensible, but I > think > this is now "cast in stone". > > >> > >> This leads me to a couple of questions: > >> - Is there a good reason for not using vop_stdallocate() for ZFS? > > > >Yes. posix_fallocate is supposed to guarantee that subsequent writes > >to the file will not fail with ENOSPC. But ZFS, being a copy-on-write > >file system, cannot possibly guarantee that. See SVN r325320. > However, vop_stdallocate() just does VOP_WRITE()s to the area (with > bytes of data all zeros). Wouldn't that satisfy the criteria? > Since it is log based, that would make it worse. The blocks aren't instantly reclaimed when marked invalid. So you'd need storage for both and the 0d blocks could cause a resource shortage when the real writes come in. ZFS doesn't have a reservation system to reserve blocks in the log for a given file... Warner >> - Should I try and support both file system types via vop_stdallocate() > >> or not support Allocate at all? > > > >Since you can't possibly support it for ZFS (not to mention other file > >systems like fusefs) you'll have to not support it at all. > It does sound like not supporting it is the best alternative. > > rick > > > > > Btw, as a bit of an aside, "cc" uses posix_fallocate() and in weird ways, > > such as offset=0, len=1. Why, I have no idea? > > > > Thanks in advance for any comments, rick > > > >
