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
probl
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,
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
http
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.
>>>
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
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
__
Ryan Stone wrote:
>On Tue, Apr 24, 2018 at 4:55 AM, Konstantin Belousov
>>>wrote:
>> +#ifndef MLX5E_MAX_RX_BYTES
>> +#defineMLX5E_MAX_RX_BYTES MCLBYTES
>> +#endif
>
>Why do you use a 2KB buffer rather than a PAGE_SIZE'd buffer?
>MJUMPAGESIZE should offer significantly better performance fo
Konstantin Belousov wrote:
>On Sat, Apr 21, 2018 at 11:30:55PM +0000, Rick Macklem wrote:
>> Konstantin Belousov wrote:
>> >On Sat, Apr 21, 2018 at 07:21:58PM +, Rick Macklem wrote:
>> >> I decided to start a new thread on current related to SCHED_ULE, since I
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 wrote:
>> > With a recent head/current kernel (doesn't happen when running a Dec.
>> > 2017 one), when I do a halt, it
ent-Type: text/plain; charset=US-ASCII
>> > Content-Transfer-Encoding: 7bit
>> > Content-Disposition: inline
>> >
>> > On Sat, 21 Apr 2018 21:09:09 + Rick Macklem wrot
>> e:
>> > > With a recent head/current kernel (doesn't happen when runn
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 coupl
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 th
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, sad
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 get
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
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 impli
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 aren't
. (Where the counter
code goes should be fine, but I am not sure I got the use of the
atomic ops correct.)
Hopefully Emmanuel can test the patch to see if it fixes his
performance problem.
rick
From: owner-freebsd-curr...@freebsd.org on
behalf of Rick
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 nfsr
Did my usual and forgot to attach it. Here's the patch, rick
From: Rick Macklem
Sent: Tuesday, November 28, 2017 6:17:13 PM
To: Emmanuel Vadot
Cc: Konstantin Belousov; FreeBSD Current; freebsd...@freebsd.org; Rick Macklem
Subject: Re: S
tions 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
Sent: Tuesday, November 28, 2017 2:09:51 PM
To: Emmanuel Vadot
Cc: Konstantin Bel
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 at
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 like to switch the vf
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 g
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
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 fol
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 li
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 ei
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 "
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
[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
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)" faili
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
>>
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
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 doe
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 do
r324136 kernel. If it still panics, I'll post again.
Thanks, rick
> Best,
> Conrad
On Sun, Oct 1, 2017 at 3:12 PM, Rick Macklem wrote:
> Hi,
>
> I get the KASSERT panic in AcpiOsGetTimer() while booting a recent (2 day old)
> kernel. When I delete the KASSERT(), the kernel b
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
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 d
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 sys
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 an
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
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 again
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 w
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 uid/gi
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
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 origin
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, whi
l Butler
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 insi
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
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
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 "nf
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 bui
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 ri
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 the
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
Sent: Wednesday, May 24, 2017 8:12:54 PM
To: Rick Macklem
Cc: freebsd-cu
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 arou
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=" i
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... Shou
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:
>>>
>
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 se
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
>rpc.
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 looks
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 "nogroup
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 a
rick
From: owner-freebsd-curr...@freebsd.org on
behalf of Rick Macklem
Sent: Friday, March 24, 2017 4:14:45 PM
To: Konstantin Belousov
Cc: Gergely Czuczy; Dimitry Andric; Ian Lepore; FreeBSD Current
Subject: Re: process killed: text file modification
I can't do commits until I g
Just in case it wasn't clear, I think this is a good idea and I think
you have a handle on any potential problems.
Good luck with it, rick
From: Toomas Soome
Sent: Tuesday, March 21, 2017 5:04:59 AM
To: Daniel Braniss
Cc: Baptiste Daroussin; Rick Ma
behalf of Konstantin Belousov
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 +0000, Rick Macklem wrote:
> Try whatever you like. However, if
riday, 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 cached NFS data).
I suspect it helped.
--
L
t by
mid-April,
I will commit this patch to help fix things in the meantime.
From: Gergely Czuczy
Sent: Thursday, March 23, 2017 2:25:11 AM
To: Rick Macklem; Konstantin Belousov
Cc: Dimitry Andric; Ian Lepore; FreeBSD Current
Subject: Re: process ki
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
___
freebs
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.
>
>
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 mult
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 that
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 s
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
>
> Bap
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.
would be small enough nothing 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
Sent: Thursday, March 16, 2017 7:46:51 PM
To: Rick Macklem; freebsd...@freebsd.org
Cc: free
Dimitry Andric wrote:
>On 17 Mar 2017, at 15:19, Konstantin Belousov wrote:
>>
>> On Fri, Mar 17, 2017 at 01:53:46PM +0000, Rick Macklem wrote:
>>> Well, I don't mind adding ncl_flush(), but it shouldn't be
>>> necessary. I actually had it in the first
e where there was an munmap before close.
Attached is an updated version with that in it, rick
From: owner-freebsd-curr...@freebsd.org on
behalf of Konstantin Belousov
Sent: Friday, March 17, 2017 4:36:05 AM
To: Rick Macklem
Cc: Dimitry Andric; Ian Le
Hope you don't mind a top post...
Attached is a little patch you could test maybe?
rick
From: owner-freebsd-curr...@freebsd.org on
behalf of Rick Macklem
Sent: Thursday, March 16, 2017 9:57:23 PM
To: Dimitry Andric; Ian Lepore
Cc: Gergely C
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 exe
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
Sent: Wednesday, March 15, 2017 10:44:33 PM
To: freebsd.
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
>rpc.
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
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
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 VOP_A
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
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 slowd
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 over
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 ke
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 dis
> Rick Macklem 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 comfortable with the
OpenBSD/N
Carsten Kunze wrote:
> Rick Macklem 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"), it should
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 freebsd
-
> 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:
> &
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 logs
d.
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 17:02:09 nfsv4-laptop login: ROOT LOGIN (roo
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
> https://lists.freebsd.org/mailman/listinfo/freebs
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
301 - 400 of 700 matches
Mail list logo