Re: slow screen updates on laptop console (i386)

on reserved port only=YES Starting nfsuserd. Starting rpcbind. Starting mountd. Starting nfsd. Updating motd:. Mounting late file systems:. Configuring vt: blanktime. Performing sanity check on sshd configuration. Starting sshd. Starting cron. Starting inetd. Tue Dec 8 17:02:04 EST 2015 Dec 8

panic "ffs_checkblk: bad block" on recent -head kernels

Hi, I get a fairly reproducible panic when doing a full kernel build on a 256Mbyte single core i386 when running recent kernels from -head. The panic is "ffs_checkblk: bad block ..". I don't actually have the block # (although I think it's just 0xfff, given the backtrace), because it

Re: slow screen updates on laptop console (i386)

Adrian Chadd wrote: > Hi, > > ok. please file a bug for that. It may be something to do with the > hardware and sleep states and skipping wakeups/interrupts or > something. > > Please try using the default again (LAPIC?) and set > kern.eventtimer.periodic=1. See if that fixes it. > Actually

Re: Partitioning on a MBR table disk fails (and destroys my data...)

Carsten Kunze wrote: > Hello, > > how is it possible to install FreeBSD in an existing empty MBR partition with > type "freebsd"? The installer does not allow this (for unknown reason), it > returns the error "no space left". What steps would be necessary to add two > freebsd-ufs and one

Re: Aw: Re: Partitioning on a MBR table disk fails (and destroys my data...)

Carsten Kunze wrote: > Rick Macklem <rmack...@uoguelph.ca> wrote: > > > Did you use "Manual" when it gets to the partitioning screen? > > When I've done this, after selecting "Manual MBR" (or whatever it's called, > > one or two below "Auto&q

Aw: Re: Aw: Re: Partitioning on a MBR table disk fails (and destroys my data...)

> Rick Macklem <rmack...@uoguelph.ca> wrote: > > > I don`t use it, but gpart is the preferred FreeBSD command. You might try > > that instead. > > Does it work with MBR or only GPT? Anyway, I'll try it. > It does handle MBR. However, since you are already com

Re: RPC request sent to 127.0.0.1 becomes from other IP on machine

- > On Thu, 10 Dec 2015, Rick Macklem wrote: > > > Hi, > > > > Mark has reported a problem via email where the nfsuserd daemon sees > > requests coming from an IP# assigned to the machine instead of 127.0.0.1. > > Here's a snippet from his message: > >

RPC request sent to 127.0.0.1 becomes from other IP on machine

Hi, Mark has reported a problem via email where the nfsuserd daemon sees requests coming from an IP# assigned to the machine instead of 127.0.0.1. Here's a snippet from his message: Ok, I have Plex in a jail and when I scan the remote NFS file share the *local* server's nfsuserd spams the

Re: NFSv4 compatibility with ESX6U2

Michael Butler wrote: > On 05/29/16 21:05, Michael Butler wrote: > > I was just fooling around with ESX this evening and trying to add an > > NFSv4 mount onto it as extra storage. Curiously, given the correct > > credentials, it will report the total volume size and free remaining but > > won't

Re: build fails post SVN r304026

Lev Serebryakov wrote: >On 13.08.2016 16:54, Michael Butler wrote: > >> Is anyone else seeing this? > Yes, I've posted message to fs@, as it is r304026 for sure (and author >was CC:ed too). Should be fixed now. Sorry about the breakage. I didn't realize the old nfsstat.c wouldn't build with the

Re: Recent FreeBSD, NFSv4 and /var/db/mounttab

Claude Buisson wrote: >Hi, > >Last month, I started switching all my systems (stable/9, stable/10, >stable/11 and current) to NFSv4, and I found that: > > on current (svn 312652) an entry is added to /var/db/mounttab by >mount_nfs(8), but not suppressed by umount(8). It can be suppressed by

Re: NFS 4.1

The vmware client will not work with the FreeBSD server at this time. It does a ReclaimComplete with file system boolean set ``true``. This isn`t supported by the FreeBSD server at this time. (vmware is the only client that does this, as far as I am know.) The fix is probably simple, but since I

Re: NFSv4 performance degradation with 12.0-CURRENT client

Konstantin Belousov wrote: >On Thu, Nov 24, 2016 at 10:45:51PM +0000, Rick Macklem wrote: >> asom...@gmail.com wrote: >> >OpenOwner Opens LockOwner LocksDelegs LocalOwn LocalOpen >> >LocalLOwn >> > 5638141453 0 0 0

Re: NFSv4 performance degradation with 12.0-CURRENT client

asom...@gmail.com wrote: [stuff snipped] >I've reproduced the issue on stock FreeBSD 12, and I've also learned >that nullfs is a required factor. Doing the buildworld directly on >the NFS mount doesn't cause any slowdown, but doing a buildworld on >the nullfs copy of the NFS mount does. The

Re: NFSv4 performance degradation with 12.0-CURRENT client

On Wed, Nov 23, 2016 at 10:17:25PM -0700, Alan Somers wrote: > I have a FreeBSD 10.3-RELEASE-p12 server exporting its home > directories over both NFSv3 and NFSv4. I have a TrueOS client (based > on 12.0-CURRENT on the drm-next-4.7 branch, built on 28-October) > mounting the home directories

Re: NFSv4 performance degradation with 12.0-CURRENT client

Konstantin Belousov wrote: [stuff snipped] >I thought that the issue was in tracking any opens and mmaps, but from this >reply it is not that clear. Do you need callback when all opens and mmaps >have ended, or only opens and mmaps for write ? If later, we already have >a suitable mechanism

Re: NFSv4 performance degradation with 12.0-CURRENT client

Alan Somers wrote: [stuff snipped] >Mounting nullfs with the nocache option, ad kib suggested, fixed the >problem. Also, applying kib's patch and then mounting nullfs with >default options also fixed the problem. Here is the nfsstat output >for "ls -al" when using kib's patch. Notice the client

Re: process killed: text file modification

, I will commit this patch to help fix things in the meantime. From: Gergely Czuczy <gergely.czu...@harmless.hu> Sent: Thursday, March 23, 2017 2:25:11 AM To: Rick Macklem; Konstantin Belousov Cc: Dimitry Andric; Ian Lepore; FreeBSD Current Subje

Re: process killed: text file modification

urr...@freebsd.org> on behalf of Konstantin Belousov <kostik...@gmail.com> Sent: Friday, March 24, 2017 3:01:41 AM To: Rick Macklem Cc: Gergely Czuczy; Dimitry Andric; Ian Lepore; FreeBSD Current Subject: Re: process killed: text file modification On Thu, Mar 23, 2017 at 09:39:00PM +,

Re: crash: umount_nfs: Current

behalf of Larry Rosenman <l...@lerctr.org> Sent: Friday, March 24, 2017 11:21:39 AM To: Rick Macklem; freebsd...@freebsd.org Cc: freebsd-current@FreeBSD.org Subject: Re: crash: umount_nfs: Current I tried my test (umount –t nfs –a && mount –t nfs –a) and no crash. (with ~84G inact

Re: NFSv2 boot & OLD_NFSV2

oussin; Rick Macklem; FreeBSD Current Subject: Re: NFSv2 boot & OLD_NFSV2 On 21. märts 2017, at 10:50, Daniel Braniss <da...@cs.huji.ac.il<mailto:da...@cs.huji.ac.il>> wrote: On 21 Mar 2017, at 10:13, Baptiste Daroussin <b...@freebsd.org<mailto:b...@freebsd.org>> wro

Re: process killed: text file modification

Konstantin Belousov wrote: [stuff snipped] > Below is something to discuss. This is not finished, but it worked for > the simple tests I performed. Clustering should be somewhat handled by > the ncl_write() as is. As an additional advantage, I removed the now > unneeded phys buffer allocation. > >

Re: crash: umount_nfs: Current

Larry Rosenman wrote: > Err, I’m at r315289…. I think the attached patch (only very lightly tested by me) will fix this crash. If you have an easy way to test it, that would be appreciated, rick clntcrash.patch Description: clntcrash.patch ___

Re: process killed: text file modification

Kostik wrote: [stuff snipped] >> >> Dirty pages are flushed by writes, so if we have a set of dirty pages and >> >> async vm_object_page_clean() is called on the vnode' vm_object, we get >> >> a bunch of delayed-write AKA dirty buffers. This is possible even after >> >> VOP_CLOSE() was done, e.g.

Re: process killed: text file modification

Dimitry Andric wrote: >On 17 Mar 2017, at 15:19, Konstantin Belousov <kostik...@gmail.com> wrote: >> >> On Fri, Mar 17, 2017 at 01:53:46PM +, Rick Macklem wrote: >>> Well, I don't mind adding ncl_flush(), but it shouldn't be >>> necessary. I act

Re: crash: umount_nfs: Current

hing would really notice it. And, of course for your case of shutdown, it would be harmless to just not free it.) rick From: Larry Rosenman <l...@lerctr.org> Sent: Thursday, March 16, 2017 7:46:51 PM To: Rick Macklem; freebsd...@freebsd.org Cc:

Re: NFSv2 boot & OLD_NFSV2

Baptiste Daroussin wrote: > On Mon, Mar 20, 2017 at 08:22:12PM +0200, Toomas Soome wrote: > > Hi! > > > > The current boot code is building NFSv3, with preprocessor conditional > > OLD_NFSV2. Should NFSv2 code still be kept around or can we burn it? > > > > rgds, > > toomas > > I vote burn > >

Re: process killed: text file modification

Gergely Czuczy wrote: [stuff snipped] > Actually I want to test it, but you guys are so vehemently discussing > it, I thought it would be better to do so, once you guys settled your > analysis on the code. Also, me not having the problem occurring, I don't > think would mean it's solved, since

Re: process killed: text file modification

Konstantin Belousov wrote: [stuff snipped] > Yes, I have to somewhat retract my claims, but then I have another set > of surprises. Righto. > I realized (remembered) that nfs has its own VOP_PUTPAGES() method. > Implementation seems to directly initiate write RPC request using the > pages as the

Re: crash: umount_nfs: Current

I believe the cause of this crash was fixed by a recent commit to head r313735 (which was MFC'd to stable/11 and stable/10). rick From: owner-freebsd-curr...@freebsd.org on behalf of Larry Rosenman

Re: process killed: text file modification

Dimitry Andric wrote: [lots of stuff snipped] > I'm also running into this problem, but while using lld. I must set > vfs.timestamp_precision to 1 (e.g. sec + ns accurate to 1/HZ) on both > the client and the server, to make it work. > > Instead of GNU ld, lld uses mmap to write to the output

Re: process killed: text file modification

AM To: Rick Macklem Cc: Dimitry Andric; Ian Lepore; Gergely Czuczy; FreeBSD Current Subject: Re: process killed: text file modification On Fri, Mar 17, 2017 at 03:10:57AM +, Rick Macklem wrote: > Hope you don't mind a top post... > Attached is a little patch you could te

Re: process killed: text file modification

Konstantin Belousov wrote: [stuff snipped] > By 'impossible' I mean some arbitrary combination of bytes which were > written by many means to the file at arbitrary moments. In other words, > the file content, or even a single page/block content is not atomic > WRT the client updates. Yes. For

Re: process killed: text file modification

Hope you don't mind a top post... Attached is a little patch you could test maybe? rick From: owner-freebsd-curr...@freebsd.org <owner-freebsd-curr...@freebsd.org> on behalf of Rick Macklem <rmack...@uoguelph.ca> Sent: Thursday, March 16, 201

Re: process killed: text file modification

From: owner-freebsd-curr...@freebsd.org <owner-freebsd-curr...@freebsd.org> on behalf of Rick Macklem <rmack...@uoguelph.ca> Sent: Friday, March 24, 2017 4:14:45 PM To: Konstantin Belousov Cc: Gergely Czuczy; Dimitry Andric; Ian Lepore; FreeBSD Current Subject: Re: process

Re: process killed: text file modification

Julian Elischer wrote: On 13/4/17 5:45 am, Rick Macklem wrote: > I have just committed a patch to head (r316745) which should fix this. > (It includes code to handle the recent change to head to make the pageouts > write through the buffer cache.) > > It will be MFC'd and sh

kernel coding of nobody/nogroup

Hi, I need to set the default uid/gid values for nobody/nogroup into kernel variables. I reverted the commit that hardcoded them, since I agree that wasn't a good thing to do. I didn't realize that "nobody" was already defined in sys/conf.h and I can use that. There is no definition for

default uid/gid for nfsuserd.c

Hi, I just added GID_NOGROUP to sys/conf.h and fixed the initial values for nobody/nogroup in the kernel. However, UID_NOBODY and GID_NOGROUP are in the _KERNEL section of sys/conf.h, so they aren't visible in userland. So, how to I set the initial uid/gid values for nfsuserd.c? (nfsuserd.c

Re: small patch for /etc/rc.d/nfsd, bugfix or POLA violation?

Cy Schubert wrote: >Rick Macklem wrote: >> Hi, >> >> The attached one line patch to /etc/rc.d/nfsd modifies the script so that i= >> t >> does not force the nfsuserd to be run when nfsv4_server_enable is set. >> (nfsuserd can still be enabled via

small patch for /etc/rc.d/nfsd, bugfix or POLA violation?

Hi, The attached one line patch to /etc/rc.d/nfsd modifies the script so that it does not force the nfsuserd to be run when nfsv4_server_enable is set. (nfsuserd can still be enabled via nfsuserd_enable="YES" is /etc/rc.conf.) Here's why I think this patch might be appropriate... (a) - The

NFSv4 server configs may need nfsuserd_enable="YES"

As of r321665, an NFSv4 server configuration that supports NFSv4 Kerberos mounts or NFSv4 clients that do not support the uid/gid in the owner/owner_group string will need to have: nfsuserd_enable="YES" in the machine's /etc/rc.conf file. The background to this is that the capability to put

Re: anyone had experience expanding uid_t and gid_t?

On 19/8/17 11:15 am, Julian Elischer wrote: >> at $JOB there are clients where 32bits is starting to chafe. >> >> Has anyone expanded them? >> >Other than a few offline comments I haven't heard anyone directly >respond to this. >Does anyone have any comments on feasibility or suggestions? >NFSV3

Re: more default uid/gid for NFS in mountd

Slawa Olhovchenkov wrote: >Rick Macklem wrote: >> Hi, >> >> Five years ago (yea, it slipped through a crack;-), Slawa reported that files >> created by root would end up owned by uid 2**32-2 (-2 as uint32_t). >> This happens if there is no "-maproot="

NFS client perf. degradation when SCHED_ULE is used (was when SMP enabled)

To briefly summarize the previous post related to perf. degradation when running a recent kernel... - kernel build running 1yr old kernel took 100minutes - same kernel build running recent kernel 148minutes (ie. Almost a 50% degradation.) As noted in the last post, I got rid of most of

Re: NFS client perf. degradation when SCHED_ULE is used (was when SMP enabled)

I wrote: >To briefly summarize the previous post related to perf. degradation when >running a >recent kernel... >- kernel build running 1yr old kernel took 100minutes >- same kernel build running recent kernel 148minutes >(ie. Almost a 50% degradation.) >As noted in the last post, I got

Re: NFS client perf. degradation when SCHED_ULE is used (was when SMP enabled)

I wrote: [stuff snipped] > So, I'd say either reverting the patch or replacing it with the "obvious > change" mentioned > in the commit message will at least mostly fix the problem. "mostly fix" was probably a bit optimistic. Here's my current #s. (All cases are the same single threaded kernel

Re: NFS client performance degradation when SMP enabled

Nope, it's an alc and the driver has very few changes between the old and new kernel (a change in the DMA channel from 3 to 4, whatever that means?). rick From: Ryan Stone <ryst...@gmail.com> Sent: Wednesday, May 24, 2017 8:12:54 PM To: Rick Mack

patch that makes max buffer cache block size tunable for review

Hi, I just put a patch here: https://reviews.freebsd.org/D10991 that makes the maximum size of a buffer cache block a tunable. This allows the NFS client to use larger I/O sized RPCs. By default, the NFS client will use the largest I/O size possible. What is actually in use can be checked via

Re: NFS client perf. degradation when SCHED_ULE is used (was when SMP enabled)

Colin Percival wrote: >On 05/28/17 13:16, Rick Macklem wrote: >> cperciva@ is running a highly parallelized buuildworld and he sees better >> slightly better elapsed times and much lower system CPU for SCHED_ULE. >> >> As such, I suspect it is the single threaded

Re: Time to increase MAXPHYS?

There is an array in aio.h sized on MAXPHYS as well. A simpler possibility might be to leave MAXPHYS as a compile time setting, but allow it to be set "per arch" and make it bigger for amd64. Good luck with it, rick From: owner-freebsd-curr...@freebsd.org

Re: post ino64: lockd no runs?

...@protected-networks.net> Sent: Sunday, June 4, 2017 8:57:44 AM To: freebsd-current; Rick Macklem Subject: post ino64: lockd no runs? It seems that {rpc.}lockd no longer runs after the ino64 changes on any of my systems after a full rebuild of src and ports. No log entries offer any insight as to why

adding extern maxbcachebuf to param.h

My recent commit (r320062) broke the arm build when it added extern int maxbcachebuf; to sys/param.h. Although I don't understand the actual failure, I believe it is caused by arm/arm/elf_note.S including param.h and then using the ELFNOTE() macro. As a temporary fix, I have committed r320070,

Re: Recent FreeBSD, NFSv4 and /var/db/mounttab

Claude Buisson wrote: [stuff snipped] > This is really an long delayed answer !! Just made it to the top of my "to do" list... > 1) I am afraid of a confusion on your side between mounttab which is > managed on the CLIENT, and mountdtab which is managed of the SERVER. Ok, now that I've looked, I

Re: Recent FreeBSD, NFSv4 and /var/db/mounttab

Claude Buisson wrote: >Hi, > >Last month, I started switching all my systems (stable/9, stable/10, >stable/11 and current) to NFSv4, and I found that: > > on current (svn 312652) an entry is added to /var/db/mounttab by >mount_nfs(8), but not suppressed by umount(8). It can be suppressed by

Re: Recent FreeBSD, NFSv4 and /var/db/mounttab

Claude Buisson wrote: >On 05/07/2017 21:09, Rick Macklem wrote: >> Claude Buisson wrote: >>> Hi, >>> >>> Last month, I started switching all my systems (stable/9, stable/10, >>> stable/11 and current) to NFSv4, and I found that: >>> >

more default uid/gid for NFS in mountd

Hi, Five years ago (yea, it slipped through a crack;-), Slawa reported that files created by root would end up owned by uid 2**32-2 (-2 as uint32_t). This happens if there is no "-maproot=" in the /etc/exports line. The cause is obvious. The value is set to -2 by default. The question is...

NFS client performance degradation when SMP enabled

Without boring you with too much detail, I have been doing development/testing of pNFS stuff (mostly server side) on a 1 year old kernel (Apr. 12, 2016). When I recently carried the code across to a recent kernel, everything seemed to work, but performance was much slower. After some fiddling

adding flex file layout support to the pNFS client

Hi, I now have a series of patches that adds Flex File layout support to the NFSv4 client for pNFS. I am now thinking about how to get them into head. 1 - I could put them up on reviews.freebsd.org, but since they are purely NFS patches and there is no Flex file layout server to test

RFC how to use kernel procs/threads efficiently

Hi, I have now dropped the client side of Flexible File Layout for pNFS into head and I believe it is basically working. Currently when talking to mirrored DS servers, it does the Write and Commit RPCs to the mirrors serially. This works, but is inefficient w.r.t. elapsed to to completion. To

Re: RFC how to use kernel procs/threads efficiently

Julian Elischer wrote: [stuff snipped] >On 10/10/17 4:25 am, Rick Macklem wrote: >> --> As such, having a fixed reasonable # of threads is probably the best >>that can be done. >>- The current patch has the # of threads as a sysctl with a default >>

pfind_locked(pid) fails when in a jail?

Hi, A problem w.r.t. the NFSv4 client's renew thread (nfscl) running up a lot of CPU when the NFSv4 mount is in a jail has been reported to the freebsd-stable@ mailing list. I know nothing about jails, but when looking at the code, the most obvious cause of this would be "pfind_locked(pid)"

Re: pfind_locked(pid) fails when in a jail?

[stuff snipped] > > > > > pfind* does not do any filtering. > > Hmm, well I have no idea why the jailed mounts get looping in here then. > > The real question though is why are you calling it in the first place. The > > calls > > I grepped in nfscl_procdoesntexist are highly suspicious - there is

anyone in the Boston area with time this week?

Hi, I really doubt that there is anyone out there interested in doing this, but I figured it can't hurt asking... RedHat is hosting a NFSv4 testing event at their facility at 34 Littleton Rd Westford, MA 01186 next week. There is no fee for attendance, but you need to physically be there

Re: Can't NFS mount ZFS volume

I have only done two NFS commits within that range. 1 - A trivial one that adds two new arguments always specified as 0, which has no change in semantics. 2 - One that only affects NFSv4 during dismount, so it shouldn't affect an NFSv3 mount. Some things to try: - get rid of rpc.statd

Re: Can't NFS mount ZFS volume

Danny Braniss wrote: > Michael Butler wrote: >> I have no idea why but using .. >> >> sudo /sbin/mount vm01:/usr/local/exports/ /mnt >> .. instead of .. >> >> sudo /sbin/mount -t nfs vm01:/usr/local/exports/ /mnt > > the not working is : > mount host:/path some-local-path > > which should

panic in AcpiOsGetTimer during boot.

Hi, I get the KASSERT panic in AcpiOsGetTimer() while booting a recent (2 day old) kernel. When I delete the KASSERT(), the kernel boots and seems to work ok. (This is the AcpiOsGetTimer() in sys/dev/acpica/Osd/OsdSchedule.c. There also seems to be one of these functions under contrib.) Here is

Re: panic in AcpiOsGetTimer during boot.

36 kernel. If it still panics, I'll post again. Thanks, rick > Best, > Conrad On Sun, Oct 1, 2017 at 3:12 PM, Rick Macklem <rmack...@uoguelph.ca> wrote: > Hi, > > I get the KASSERT panic in AcpiOsGetTimer() while booting a recent (2 day old) > kernel. When I delete the KASS

Re: Can't NFS mount ZFS volume

Michael Butler wrote: > I have no idea why but using .. > > sudo /sbin/mount vm01:/usr/local/exports/ /mnt This is weird. I would have thought they would both result in the same behaviour. > .. instead of .. > > sudo /sbin/mount -t nfs vm01:/usr/local/exports/ /mnt Did this work with the older

Re: RFC how to use kernel procs/threads efficiently

Ian Lepore wrote: [stuff snipped] >taskqueue(9) is an existing mechanism to enqueue functions to execute >asynch using a pool of threads, but it doesn't answer the scalability >questions. In fact it may make them harder, inasmuch as I don't think >there's

Re: RFC how to use kernel procs/threads efficiently

Ian Lepore wrote: >On Fri, 2017-10-06 at 19:02 +0000, Rick Macklem wrote: >> Hi, >> >> I have now dropped the client side of Flexible File Layout for pNFS into head >> and I believe it is basically working. >> Currently when talking to mirrored DS servers, it

Re: pfind_locked(pid) fails when in a jail?

Mateusz Guzik wrote: [lots of stuff snipped] > I proposed registration of per-process callbacks, not filtering. > The code would just walk the list/table/whatever and call everything on > it - they asked for it. Yep, this would work for the NFSv4 client. Way back when, all I did in OpenBSD was add

Re: Switch vfs.nfsd.issue_delegations to TUNABLE ?

Konstantin Belousov wrote: >On Tue, Nov 28, 2017 at 02:26:10PM +0100, Emmanuel Vadot wrote: >> On Tue, 28 Nov 2017 13:04:28 +0200 >> Konstantin Belousov wrote: >> >> > On Tue, Nov 28, 2017 at 11:41:36AM +0100, Emmanuel Vadot wrote: >> > > >> > > Hello, >> > > >> > > I would

Re: Switch vfs.nfsd.issue_delegations to TUNABLE ?

Emmanuel Vadot wrote: >I wrote: >> Since it defaults to "disabled", I don't see why a tunable would be >> necessary? >> (Just do nothing and delegations don't happen. If you want the server >> to issue delegations, then use the sysctl to turn them on. If you want to >> turn >> them off again

Re: Switch vfs.nfsd.issue_delegations to TUNABLE ?

and use atomics to increment/decrement it so that it is SMP safe without acquiring any lock. If you can test this, please let me know how it goes? rick From: Rick Macklem <rmack...@uoguelph.ca> Sent: Tuesday, November 28, 2017 2:09:51 PM To: Emmanuel Va

Re: Switch vfs.nfsd.issue_delegations to TUNABLE ?

Did my usual and forgot to attach it. Here's the patch, rick From: Rick Macklem <rmack...@uoguelph.ca> Sent: Tuesday, November 28, 2017 6:17:13 PM To: Emmanuel Vadot Cc: Konstantin Belousov; FreeBSD Current; freebsd...@freebsd.org; Rick Macklem Subje

Re: Mergemaster won't run on NFS mount

Thomas Laus wrote: >I have been updating FreeBSD for years on my fastest computer and then >NFS mounting /usr/src and /usr/obj to share with other PC's. I just >updated FreeBSD-CURRENT to 326070 and was able to install the kernel and >world. When I attempted to run mergemaster, I received the

Re: Mergemaster won't run on NFS mount

Thomas Laus wrote: >My /etc/exports file is empty. I have set the sharenfs property to >'YES" on the /usr/obj and /usr/src data sets. The ZFS filesystem >handles NFS shares internally from the documenation. It still reloads the exports, so the outcome is the same. >In any event, >this is how my

Re: Switch vfs.nfsd.issue_delegations to TUNABLE ?

Emmanuel Vadot wrote: [stuff snipped] > I haven't test by I can say that it will work, I actually wondered at >first doing that. The problem with this patch is what I tried to >describe in my first and following mails, since you can turn on and off >delegation you can still have delegation (so

pNFS server code merge into head/current

Hi, There is a source tree in svn at projects/pnfs-planb-server which adds support for configuring a single Metadata Server (MDS) and multiple Data Servers (DS) to create a simple pNFS service. (In a pNFS server the Read/Write operations are separated from the rest of the metadata operations and

Re: NFSv4.2

Stefan Wendler wrote: > I was wondering when and if FreeBSD will support NFSv4.2 > Is there anything planned yet? Someday, but no specific plans at this point. Is there some specific feature in NFSv4.2 that you are looking for? I ask because there isn't a lot of new features in NFSv4.2 that

Re: NFSv4.2

Stefan Wendler wrote: > We would like to use the file copy and the sparse features of 4.2 in our > Setup. Do you know if any of the two has been implemented yet? The > sparse feature would be more important than the file copy feature though. No idea (except that NFSv4.2 isn't in FreeBSD which

Re: Switch vfs.nfsd.issue_delegations to TUNABLE ?

urr...@freebsd.org> on behalf of Rick Macklem <rmack...@uoguelph.ca> Sent: Wednesday, November 29, 2017 12:28:05 PM To: Emmanuel Vadot Cc: Konstantin Belousov; FreeBSD Current; freebsd...@freebsd.org Subject: Re: Switch vfs.nfsd.issue_delegations to TUNABLE ? Emmanuel Vadot wrote: [stuff

Re: NFSv3 issues with latest -current

Yuri Pankov wrote: > All file operations (e.g. copying the file over NFSv3 for me) seem to be > stuck running the latest -current (r325100). Reverting just the kernel > to r323779 (arbitrary chosen) seems to help. I noticed the "Stale file > handle when mounting nfs" message but I don't get the

Re: NFSv3 issues with latest -current

Cy Schubert wrote: [stuff snipped] >The sysctl is net.inet.tcp.tso. You can also disable tso through ifconfig >for an interface. > For testing this case, I'd recommend using the sysctl. Since the net device driver is often the culprit, that device driver might not handle the "ifconfig" correctly

Re: NFSv3 issues with latest -current

Rodney W. Grimes wrote: [stuff snipped] > I wrote: >> Btw, NFS often causes this because... >> - Typically TSO is limited to a 64K packet (including TCP/IP and MAC >> headers). >> - When NFS does reading/writing, it will do 64K + NFS, TCP/IP and MAC headers >> for an RPC (or a multiple of 64K

Re: how do I use the make universe machines?

Just replying to one of the messages at random... Benjamin Kaduk wrote: [stuff snipped] >I think https://www.freebsd.org/internal/machines.html sounds like >the page you're looking for. (universe is just a top-level make >target like buildworld, but will take a while on non-beefy >hardware.) Yea,

RFC: ESXi client is nasty, what should I do?

Hi, I realized that the subject line "ESXi NFSv4.1 client id is nasty" wouldn't have indicated that I was looking for comments w.r.t. how to handle this poorly behaved client. Please go to the "ESXi NFSv4.1 client id is nasty" thread and comment. (It should be in the archive, if you already

Re: ESXi NFSv4.1 client id is nasty

essage and fail the mount, if the "hack" sysctl isn't set? rick [stuff snipped] From: Steve Wills Sent: Monday, June 18, 2018 5:21:10 PM To: Rick Macklem; freebsd-current@freebsd.org Cc: andreas.n...@frequentis.com Subject: Re: ESXi NFSv4.1 cl

Heads Up: pNFS server merge committed to head

Since I only got one response to my query w.r.t. should projects/pnfs-planb-server be merged into head and it wasn't negative, I went with "no news is good news" and did the merge/commit. It is now in head as r335012. Since it has survived a recent "make universe", I hope it won't cause build

Re: utilities in /usr/bin or /usr/sbin?

I wrote: >I have three new utilities that are mainly useful for managing the pNFS server >committed as r335130. Oops, I meant r334930, although it doesn't really affect the question. >In the projects tree, I have them in /usr/bin and man section 1. However, >since they are mostly useful to a

utilities in /usr/bin or /usr/sbin?

Hi, I have three new utilities that are mainly useful for managing the pNFS server committed as r335130. In the projects tree, I have them in /usr/bin and man section 1. However, since they are mostly useful to a sysadmin managing the pNFS service, I'm thinking that maybe they should be in

Re: utilities in /usr/bin or /usr/sbin?

Rodney W. Grimes wrote: ?> On Thu, Jun 14, 2018 at 2:15 PM, Rick Macklem wrote: >> >> > Hi, >> > >> > I have three new utilities that are mainly useful for managing the pNFS >> > server >> > committed as r335130. >> > >> >

review of nfsd rc.d script patch

Hi, For the pNFS service MDS machine, the nfsd can't be started until all nfs mounts in /etc/fstab are done. I think that adding "mountcritremote" to the "# REQUIRE:" line is sufficient to do this? I don't think delaying the startup of the nfsd daemon until after any NFS mounts are done will do

Re: NFSv4.1 server deficiencies fixed for ESXi client

Rodney W. Grimes wrote: [stuff snipped] >Have you any contact with VMWare so that they might fix the issues >in their code, rather than having to put hacks in FreeBSD for these >issues? Nope. I tried an email to nf...@ietf.org about one issue (that isn't yet resolved related to it complaining

ESXi NFSv4.1 client id is nasty

Hi, Andreas Nagy has been doing a lot of testing of the NFSv4.1 client in ESXi 6.5u1 (VMware) against the FreeBSD server. I have given him a bunch of hackish patches to try and some of them do help. However not all issues are resolved. The problem is that these hacks pretty obviously violate the

NFSv4.1 server deficiencies fixed for ESXi client

Hi, Since I posted w.r.t. issues that seem to violate the RFC, I figured I should also post ones that identified deficiencies in the FreeBSD server. These have either been patched in head/current or will be soon and will be MFC'd. - BindConnectiontoSession wasn't implemented. It is never used

SPDX-License-Id for new files

I have a few (3) new files in the projects/pnfs-planb-server subversion tree that all have the 2 clause FreeBSD copyright. Do I just add the "SPDX..." line for this license at the top of the copyright comment or is there some other exercise needed to be done for this? Thanks, rick

how to deal with variable set but not used warnings?

mmacy has sent me a bunch of warnings of the "variable set but not used" kind generated by gcc8. When I've looked at the code, these are for RPC arguments I parse but do not use at this time. I'd like to leave the code in place, since these arguments may be needed in the future and it is hard to

Re: how to deal with variable set but not used warnings?

Matthew Macy wrote: >On Sun, Jun 3, 2018 at 2:40 PM, Theron wrote: >>> 4. Disable the stupid warning in the Makefile / build system. If you don't >>> care, and there's a good reason for what you are doing (sounds like there >>> is), better to just disable the warning as so much useless noise. >>>

how do I use the make universe machines?

I've heard mention of "make universe" machines multiple times, but have no idea how to use them? Is there doc on this? Thanks, rick ps: I'll admit I haven't looked at the developer's guide in a long time. ___ freebsd-current@freebsd.org mailing list

<    1   2   3   4   5   6   7   >