Julian Elischer wrote:
> On 4/25/15 4:28 AM, John Baldwin wrote:
> > On Saturday, April 25, 2015 02:36:24 AM Julian Elischer wrote:
> >> On 4/25/15 1:30 AM, Julian Elischer wrote:
> >>> On 4/24/15 10:59 PM, John Baldwin wrote:
> On Friday, April 24, 2015 01:02:39 PM Julian Elischer wrote:
> >>
Julian Elischer wrote:
> On 4/25/15 5:52 AM, Jilles Tjoelker wrote:
> > On Fri, Apr 24, 2015 at 04:28:12PM -0400, John Baldwin wrote:
> >> Yes, this isn't at all safe. There's no guarantee whatsoever that
> >> the offset on the directory fd that isn't something returned by
> >> getdirentries has a
Julian Elischer wrote:
> On 4/25/15 9:39 AM, Rick Macklem wrote:
> > Jilles Tjoelker wrote:
> >> On Fri, Apr 24, 2015 at 04:28:12PM -0400, John Baldwin wrote:
> >>> Yes, this isn't at all safe. There's no guarantee whatsoever
> >>> that
>
Julian Elischer wrote:
> On 4/25/15 9:39 AM, Rick Macklem wrote:
> > Jilles Tjoelker wrote:
> >> On Fri, Apr 24, 2015 at 04:28:12PM -0400, John Baldwin wrote:
> >>> Yes, this isn't at all safe. There's no guarantee whatsoever
> >>> that
>
Julian Elischer wrote:
> On 4/25/15 4:28 AM, John Baldwin wrote:
> > On Saturday, April 25, 2015 02:36:24 AM Julian Elischer wrote:
> >> On 4/25/15 1:30 AM, Julian Elischer wrote:
> >>> On 4/24/15 10:59 PM, John Baldwin wrote:
> Index: head/lib/libc/gen/telldir.c
> ===
John Baldwin wrote:
> On Thursday, April 30, 2015 02:56:25 PM Julian Elischer wrote:
> > We really need to do something because the current system is really
> > broken.
> > And the fact that dirent has *32 bit* inode number in it was a
> > shock.. I'd presumed
> > that had gone the way of the dino
Julian Elischer wrote:
> On 5/5/15 8:42 AM, Rick Macklem wrote:
> > Julian Elischer wrote:
> >> On 5/3/15 10:33 PM, Jilles Tjoelker wrote:
> >>> On Fri, May 01, 2015 at 07:17:42PM +0300, Konstantin Belousov
> >>> wrote:
> >>>> On Fri
Julian Elischer wrote:
> On 5/3/15 10:33 PM, Jilles Tjoelker wrote:
> > On Fri, May 01, 2015 at 07:17:42PM +0300, Konstantin Belousov
> > wrote:
> >> On Fri, May 01, 2015 at 03:04:51PM +0800, Julian Elischer wrote:
> >>> if you are interested in readdir(3), seekdir(3) and telldir(3)
> >>> then
> >>
Julian Elischer wrote:
> On 5/3/15 10:33 PM, Jilles Tjoelker wrote:
> > On Fri, May 01, 2015 at 07:17:42PM +0300, Konstantin Belousov
> > wrote:
> >> On Fri, May 01, 2015 at 03:04:51PM +0800, Julian Elischer wrote:
> >>> if you are interested in readdir(3), seekdir(3) and telldir(3)
> >>> then
> >>
David Boyd reported a problem to freebsd-current@ w.r.t. the MNT_AUTOMOUNTED
flag getting cleared by mountd.
http://docs.FreeBSD.org/cgi/mid.cgi?1429477202.29812.38.camel
I just took a look at this and it's kinda ugly...
mountd acquires a list of mounts via getmntinfo() and then does an
nmount()
Doug Rabson wrote:
> You could add a single integer-valued vfsopt which holds the
> high-order
> bits of f_flags?
>
Yes, that sounds better than any of my ideas. I'll code up a patch
and put it up for review unless someone has a better solution.
Thanks Doug, rick
> On 7 May
review/comment on this. (Feel free to add yourself as a reviewer, etc.)
Also, David, if you can test this patch, it would be appreciated.
Thanks for the suggestion Doug, rick
> On 7 May 2015 at 02:10, Rick Macklem wrote:
>
> > David Boyd reported a problem to freebsd-current@ w
d.
>
> Thanks for the suggestion Doug, rick
>
> > On 7 May 2015 at 02:10, Rick Macklem wrote:
> >
> > > David Boyd reported a problem to freebsd-current@ w.r.t. the
> > > MNT_AUTOMOUNTED
> > > flag getting cleared by mountd.
> > > h
David Boyd wrote:
> On Sun, 2015-05-10 at 09:07 -0400, Rick Macklem wrote:
> > Oops, I did my usual and forgot to attach the patch.
> >
> > Here it is, rick
> >
> > - Original Message -
> > > Doug Rabson wrote:
> > > > You co
Hi,
I just MFC'd a patch from head to stable/10 that defines some
tunables using CTLFLAG_RDTUN. Although the MFC didn't break
anything, the tunables don't get changed by the values in /boot/loader.conf.
By applying a patch like this:
SYSCTL_DECL(_vfs_nfsd);
intnfsrv_statehashsize = NFSSTATE
Daniel O'Conner wrote:
> I am seeing the following breakage when building -current and the source is
> on NFS
>
> make -j 4 buildworld
> ...
> --- rescue.all__D ---
> --- rescue ---
> MAKEOBJDIRPREFIX=/usr/obj/src/FreeBSD-HEAD/rescue/rescue make -f rescue.mk
> exe
> --- sbin.all__D ---
> --- pfctl
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 ser
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 ser
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
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
> > > To: Rick Macklem
> > > Cc: FreeBSD Current
> > > Subject: Re: panic "ffs_checkbl
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 I'v
Alexander Kabaev wrote:
> On Mon, 7 Dec 2015 09:02:35 -0500 (EST)
> Rick Macklem wrote:
>
> > Hi,
> >
> > When running FreeBSD-current on an old i386 laptop, the console
> > screen is intermittently slow to display output. The hesitations
> > can be sev
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 made
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
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
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
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
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
-
> 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:
> &
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
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
> 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
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
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
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
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
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
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
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
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
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.
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.
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
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
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
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
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
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.
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
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
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]
> 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
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.
>
>
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
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
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
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
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
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
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
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
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
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.
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:
>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:
>>>
>
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Harald Schmalzbauer wrote:
> schrieb Attilio Rao am 01.10.2011 16:49 (localtime):
> > Can you please show the panic message?
>
> Sorry, I forgot to add it here:
>
> free indoe /var/123088 had 8 blocks
> panic: VAPPEND withour VWRITE
> >> cpuid = 0
> >> KDB: enter: panic
> >> [ thread pid 1445 tid
Bjoern A. Zeeb wrote:
> Hi,
>
> as a result of a make buildkernel && make installkernel && reboot all
> on NFS I got this with a HEAD SVN source at r226465. I cannot dump
> unfortunately and it seems I just killed the obj tree for this kernel
> though it should be very close.
>
> Oct 18 10:03:22
Dan The Man wrote:
> Just want to include some errors from rsync trying to copy files using
> NFSV4. These files copy fine using NFSV3
>
>
> rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/A-E/A/Ace of
> Base/The Bridge/Ace of Base-My D\#351j\#340 Vu-09-The Bridge.wma")
> failed:
> Inva
Hi,
I have just committed r227809 to head/current which enables the
new/default NFS server's use of shared vnode locks for Read,
Readdir, Readlink, Getattr and Access.
Although it is hoped that this will improve performance for these
operations when multiple ones are performed concurrently on the
Sean Bruno wrote:
> Not sure what this all means, but when I attempt to check out HEAD on
> an
> NFS mount in the fbsd cluster (nfs server is a netapp filer), I'm
> getting an odd failure error.
>
>
> FreeBSD bhyve.freebsd.org 10.0-CURRENT FreeBSD 10.0-CURRENT #0
> r227883:
> Wed Nov 23 06:08:40
Dinitry Andric wrote:
> On 2011-11-23 17:41, Sean Bruno wrote:
> > Not sure what this all means, but when I attempt to check out HEAD
> > on an
> > NFS mount in the fbsd cluster (nfs server is a netapp filer), I'm
> > getting an odd failure error.
> >
> >
> > FreeBSD bhyve.freebsd.org 10.0-CURRENT
Dimitry Andric wrote:
> On 2011-11-23 17:41, Sean Bruno wrote:
> > Not sure what this all means, but when I attempt to check out HEAD
> > on an
> > NFS mount in the fbsd cluster (nfs server is a netapp filer), I'm
> > getting an odd failure error.
> >
> >
> > FreeBSD bhyve.freebsd.org 10.0-CURRENT
Sean Bruno wrote:
> On Wed, 2011-11-23 at 09:58 -0800, Rick Macklem wrote:
> > I don't know if Dimitry tried this, but you could also try the
> > "nolockd" option, so that byte range locking is done locally in
> > the client and avoids the NLM.
> >
> &
erisk.sunsaturn.com:/usr/obj/usr/src/sys/MYKERNEL amd64
>
>
> Can view either file here:
>
> http://www.sunsaturn.com/nfsv4/nfs.txt (raw dump)
> http://www.sunsaturn.com/nfsv4/nfs2.txt (-r dump)
>
>
>
> Dan.
>
>
> --
> Dan The Man
> CTO/ Senio
Pawel Jakub Dawidek wrote:
> On Fri, Nov 25, 2011 at 01:20:01PM -0600, Mark Felder wrote:
> > 13:14:32 nas:~ > uname -a
> > FreeBSD nas.feld.me 9.0-PRERELEASE FreeBSD 9.0-PRERELEASE #3
> > r227971M:
> > Fri Nov 25 10:07:48 CST 2011
> > r...@nas.feld.me:/usr/obj/tank/svn/sys/GENERIC amd64
> >
> > Th
John wrote:
> After pondering the best way to allow the VOP_ACCESS() call to
> only query for the permissions really needed, I've come up with
> a patch that minimally adds one parameter to the nlm_get_vfs_state()
> function call with the lock type from the original argp.
>
> http://people.freebsd
John wrote:
> After pondering the best way to allow the VOP_ACCESS() call to
> only query for the permissions really needed, I've come up with
> a patch that minimally adds one parameter to the nlm_get_vfs_state()
> function call with the lock type from the original argp.
>
> http://people.freebsd
Dimitry Andric wrote:
> On 2011-11-23 19:26, Sean Bruno wrote:
> > On Wed, 2011-11-23 at 09:58 -0800, Rick Macklem wrote:
> >> I don't know if Dimitry tried this, but you could also try the
> >> "nolockd" option, so that byte range locking is done loc
John De wrote:
> Hi Folks,
>
> I have a 9-prerelease system where I've been testing nfs/zfs. The
> system has been working quite well until moving the server to a
> multihomed
> configuration.
>
> Given the following:
>
> nfsd: master (nfsd)
> nfsd: server (nfsd)
> /usr/sbin/rpcbind -h 10.24.6.3
Hi,
A recent NFS client crash:
http://glebius.int.ru/tmp/nfs_panic.jpg
appears to have happened because some field is
bogus when crfree() is called. I've asked Gleb
to disassemble crfree() for me, so I can try and
see exactly which field causes the crash, however...
Basically, the code:
newc
John Baldwin wrote:
> On Monday, December 19, 2011 8:21:45 pm Rick Macklem wrote:
> > Hi,
> >
> > A recent NFS client crash:
> > http://glebius.int.ru/tmp/nfs_panic.jpg
> > appears to have happened because some field is
> > bogus when crfree() is called. I&
First off, I had no idea which mailing list would be appropriate
for this, so apologies in advance if I chose the wrong one.
For NFSv4.1 pNFS, there are layout drivers in Linux that I would
like to reuse for the FreeBSD client. (Re-writing these drivers
from scratch would be a lot of work and diff
101 - 200 of 700 matches
Mail list logo
