Re: i386 hangs during halt "vnodes remaining... 0 time out"

Konstantin Belousov wrote: >On Sat, Apr 21, 2018 at 11:49:34PM +0200, Tijl Coosemans wrote: >> On Sat, 21 Apr 2018 21:09:09 +0000 Rick Macklem <rmack...@uoguelph.ca> wrote: >> > With a recent head/current kernel (doesn't happen when running a Dec. >> > 2017 one),

Re: i386 hangs during halt "vnodes remaining... 0 time out"

ent-Type: text/plain; charset=US-ASCII >> > Content-Transfer-Encoding: 7bit >> > Content-Disposition: inline >> > >> > On Sat, 21 Apr 2018 21:09:09 + Rick Macklem <rmack...@uoguelph.ca> wrot >> e: >> > > With a recent head/current kernel

Re: SCHED_ULE makes 256Mbyte i386 unusable

Konstantin Belousov wrote: >On Sat, Apr 21, 2018 at 07:21:58PM +0000, Rick Macklem wrote: >> I decided to start a new thread on current related to SCHED_ULE, since I see >> more than just performance degradation and on a recent current kernel. >> (I cc'd a couple of

i386 hangs during halt "vnodes remaining... 0 time out"

With a recent head/current kernel (doesn't happen when running a Dec. 2017 one), when I do a halt, it gets as far as: vnodes remaining... 0 time out and that's it (the time out appears several seconds after the first "0"). With a Dec. 2017 kernel there would be several "0"s printed. It appears

SCHED_ULE makes 256Mbyte i386 unusable

I decided to start a new thread on current related to SCHED_ULE, since I see more than just performance degradation and on a recent current kernel. (I cc'd a couple of the people discussing performance problems in freebsd-stable recently under a subject line of "Re: kern.sched.quantum: Creepy,

Re: anyone running with ngroups increased from 16?

Brooks Davis wrote: >On Mon, Apr 16, 2018 at 06:37:53PM +0800, Julian Elischer wrote: >> Windows users seem to have an almost unlimited number of groups and=20 >> soem places seem to use them a LOT. >> This gives Posix systems problems with deciding how to handle them=20 >> all. Especially when

Re: anyone running with ngroups increased from 16?

Julian Elischer wrote: >On 16/4/18 6:37 pm, Julian Elischer wrote: >> Windows users seem to have an almost unlimited number of groups and >> soem places seem to use them a LOT. >> This gives Posix systems problems with deciding how to handle them >> all. Especially when getting >> user credentials

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: 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: 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: 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

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: 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 ?

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 ?

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

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: 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: 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: 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: 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

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: 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: 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

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: 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 >>

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

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: 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

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: 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

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: 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

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

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

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

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: 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

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: 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

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: 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

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)

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 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

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 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

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

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="

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...

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: >>> >

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

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

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

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

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: 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

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: 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: 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

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: 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

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: 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

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: 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: 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: 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

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

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: 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: 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

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: 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

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: 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: 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

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: 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

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: slow screen updates on laptop console (i386)

John Baldwin wrote: > On Monday, December 07, 2015 06:01:08 PM Rick Macklem wrote: > > Adrian Chadd wrote: > > > Hi, > > > > > > ok. please file a bug for that. It may be something to do with the > > > hardware and sleep states and s

Re: slow screen updates on laptop console (i386)

John Baldwin wrote: > On Monday, December 07, 2015 06:01:08 PM Rick Macklem wrote: > > Adrian Chadd wrote: > > > Hi, > > > > > > ok. please file a bug for that. It may be something to do with the > > > hardware and sleep states and s

Re: slow screen updates on laptop console (i386)

Adrian Chadd wrote: > Hi, > > Yea - try setting hw.acpi.cpu.cx_lowest=C1 and re-test. > Yep, with this setting, LAPIC seems to work fine. rick > > -a > ___ > freebsd-current@freebsd.org mailing list >

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

slow screen updates on laptop console (i386)

Hi, When running FreeBSD-current on an old i386 laptop, the console screen is intermittently slow to display output. The hesitations can be several seconds. Sometimes it shows up when I'm typing such that it takes seconds for the characters to echo. I think it is the display/output side, since

Re: slow screen updates on laptop console (i386)

Alexander Kabaev wrote: > On Mon, 7 Dec 2015 09:02:35 -0500 (EST) > Rick Macklem <rmack...@uoguelph.ca> wrote: > > > Hi, > > > > When running FreeBSD-current on an old i386 laptop, the console > > screen is intermittently slow to display output. The

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: panic "ffs_checkblk: bad block" on recent -head kernels

Mateusz Guzik wrote: > On Thu, Dec 03, 2015 at 03:07:48PM -0800, Kirk McKusick wrote: > > > Date: Thu, 3 Dec 2015 23:47:52 +0100 > > > From: Mateusz Guzik <mjgu...@gmail.com> > > > To: Rick Macklem <rmack...@uoguelph.ca> > > > Cc: FreeBSD Curr

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: Kernel panic with fresh current, probably nfs related

Joel Dahl wrote: Hi, I hit a kernel panic running a fresh -CURRENT today. This machine is my home NFS server and it exports src and obj to a bunch of other machines. During an installkernel on one of the other machines (using the src and obj exports from the NFS server) the NFS server

Re: Kernel panic with fresh current, probably nfs related

Joel Dahl wrote: Hi, I hit a kernel panic running a fresh -CURRENT today. This machine is my home NFS server and it exports src and obj to a bunch of other machines. During an installkernel on one of the other machines (using the src and obj exports from the NFS server) the NFS server

<    1   2   3   4   5   6   7   >