Re: FreeBSD NFS client/Linux NFS server issue
On Fri, 22 Jan 2010 17:13:09 -0500 (EST) Rick Macklem wrote: On Fri, 22 Jan 2010, Rick Macklem wrote: There should probably be some sort of 3 way handshake between the code in nfs_asyncio() after calling nfs_nfsnewiod() and the code near the beginning of nfssvc_iod(), but I think the following somewhat cheesy fix might do the trick: [stuff deleted] I know it's a little weird to reply to my own posting, but I think this might be a reasonable patch (I have only tested it for a few minutes at this point). I basically redefined nfs_iodwant[] as a tri-state variable (although it was a struct proc *, it was only tested NULL/non-NULL). 0 - was NULL 1 - was non-NULL -1 - just created by nfs_asyncio() and will be used by it I'll keep testing it, but hopefully someone else can test and/or review it... rick I applied your patch to FreeBSD8.0 (the box I get on weekend :-), mounted 10 shares, set vfs.nfs.iodmaxidle=10 (to have nfsiod creation more frequently) and have been running tests for 4 hours -- just to check the patch does not break anything. No issues have been detected. It would be very nice to have this patch committed. -- Mikolaj Golub ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD NFS client/Linux NFS server issue
On Sat, 23 Jan 2010, Mikolaj Golub wrote: I applied your patch to FreeBSD8.0 (the box I get on weekend :-), mounted 10 shares, set vfs.nfs.iodmaxidle=10 (to have nfsiod creation more frequently) and have been running tests for 4 hours -- just to check the patch does not break anything. No issues have been detected. It would be very nice to have this patch committed. Thanks for doing the testing and good work w.r.t. figuring out the race. (I'll admit I didn't really have a clue what was causing your problem.) rick ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD NFS client/Linux NFS server issue
On Tue, 19 Jan 2010 10:02:57 +0200 Mikolaj Golub wrote:
So, on some of our freebsd7.1 nfs clients (and it looks like we have had
similar case with 6.3), which have several nfs mounts to the same CentOS 5.3
NFS server (mount options: rw,-3,-T,-s,-i,-r=32768,-w=32768,-o=noinet6), at
some moment the access to one of the NFS mount gets stuck, while the access to
the other mounts works ok.
In all cases we have been observed so far the first gotten stuck process was
php script (or two) that was (were) writing to logs file (appending). In
tcpdump we see that every write to the file causes the sequence of the
following rpc: ACCESS - READ - WRITE - COMMIT. And at some moment this stops
after READ rpc call and successful reply.
After this in tcpdump successful readdir/access/lookup/fstat calls are
observed from our other utilities, which just check the presence of some files
and they work ok (df also works). The php process at this state is in bo_wwait
invalidating buffer cache [1].
If at this time we try accessing the share with mc then it hangs acquiring the
vn_lock held by php process [2] and after this any operations with this NFS
share hang (df hangs too).
If instead some other process is started that writes to some other file on
this share (append) then the first process unfreezes too (starting from
WRITE rpc, so there is no any retransmits).
So it looks for me that the problem here is that eventually problem nfsmount
ends up in this state:
(kgdb) p *nmp
$1 = {nm_mtx = {lock_object = {lo_name = 0xc0b808ee NFSmount lock,
lo_type = 0xc0b808ee NFSmount lock, lo_flags = 16973824,
lo_witness_data = {lod_list = {
stqe_next = 0x0}, lod_witness = 0x0}}, mtx_lock = 4, mtx_recurse =
0}, nm_flag = 35399,
nm_state = 1310720, nm_mountp = 0xc6b472cc, nm_numgrps = 16,
nm_fh = \001\000\000\000\000\223\000\000\...@\003\n, '\0' repeats 115
times, nm_fhsize = 12,
nm_rpcclnt = {rc_flag = 0, rc_wsize = 0, rc_rsize = 0, rc_name = 0x0, rc_so =
0x0, rc_sotype = 0,
rc_soproto = 0, rc_soflags = 0, rc_timeo = 0, rc_retry = 0, rc_srtt = {0,
0, 0, 0}, rc_sdrtt = {0,
0, 0, 0}, rc_sent = 0, rc_cwnd = 0, rc_timeouts = 0, rc_deadthresh = 0,
rc_authtype = 0,
rc_auth = 0x0, rc_prog = 0x0, rc_proctlen = 0, rc_proct = 0x0}, nm_so =
0xc6e81d00, nm_sotype = 1,
nm_soproto = 0, nm_soflags = 44, nm_nam = 0xc6948640, nm_timeo = 6000,
nm_retry = 2, nm_srtt = {15,
15, 31, 52}, nm_sdrtt = {3, 3, 15, 15}, nm_sent = 0, nm_cwnd = 4096,
nm_timeouts = 0,
nm_deadthresh = 9, nm_rsize = 32768, nm_wsize = 32768, nm_readdirsize = 4096,
nm_readahead = 1,
nm_wcommitsize = 1177026, nm_acdirmin = 30, nm_acdirmax = 60, nm_acregmin =
3, nm_acregmax = 60,
nm_verf = JК╬W\000\004oМ, nm_bufq = {tqh_first = 0xda82dc70, tqh_last =
0xda8058e0},
nm_bufqlen = 2, nm_bufqwant = 0, nm_bufqiods = 1, nm_maxfilesize =
1099511627775,
nm_rpcops = 0xc0c2b5bc, nm_tprintf_initial_delay = 12, nm_tprintf_delay = 30,
nm_nfstcpstate = {
rpcresid = 0, flags = 1, sock_send_inprog = 0},
nm_hostname = 172.30.10.92\000/var/www/app31, '\0' repeats 60 times,
nm_clientid = 0, nm_fsid = {
val = {0, 0}}, nm_lease_time = 0, nm_last_renewal = 0}
We have nonempty nm_bufq, nm_bufqiods = 1, but actually there is no nfsiod
thread run for this mount, which is wrong -- nm_bufq will not be emptied until
some other process starts writing to the nfsmount and starts nfsiod thread for
this mount.
Reviewing the code how it could happen I see the following path. Could someone
confirm or disprove me?
in nfs_bio.c:nfs_asyncio() we have:
1363 mtx_lock(nfs_iod_mtx);
...
1374 /*
1375 * Find a free iod to process this request.
1376 */
1377 for (iod = 0; iod nfs_numasync; iod++)
1378 if (nfs_iodwant[iod]) {
1379 gotiod = TRUE;
1380 break;
1381 }
1382
1383 /*
1384 * Try to create one if none are free.
1385 */
1386 if (!gotiod) {
1387 iod = nfs_nfsiodnew();
1388 if (iod != -1)
1389 gotiod = TRUE;
1390 }
Let's consider situation when new nfsiod is created.
nfs_nfsiod.c:nfs_nfsiodnew() before creating nfssvc_iod thread unlocks
nfs_iod_mtx:
179 mtx_unlock(nfs_iod_mtx);
180 error = kthread_create(nfssvc_iod, nfs_asyncdaemon + i, NULL,
RFHIGHPID,
181 0, nfsiod %d, newiod);
182 mtx_lock(nfs_iod_mtx);
And nfs_nfsiod.c:nfssvc_iod() do the followin:
226 mtx_lock(nfs_iod_mtx);
...
238 nfs_iodwant[myiod] = curthread-td_proc;
239 nfs_iodmount[myiod] = NULL;
...
244 error = msleep(nfs_iodwant[myiod], nfs_iod_mtx, PWAIT
| PCATCH,
245 -, timo);
Let's at this moment another nfs_asyncio()
Re: FreeBSD NFS client/Linux NFS server issue
On Fri, 22 Jan 2010, Mikolaj Golub wrote:
We have nonempty nm_bufq, nm_bufqiods = 1, but actually there is no nfsiod
thread run for this mount, which is wrong -- nm_bufq will not be emptied until
some other process starts writing to the nfsmount and starts nfsiod thread for
this mount.
Reviewing the code how it could happen I see the following path. Could someone
confirm or disprove me?
in nfs_bio.c:nfs_asyncio() we have:
1363 mtx_lock(nfs_iod_mtx);
...
1374 /*
1375 * Find a free iod to process this request.
1376 */
1377 for (iod = 0; iod nfs_numasync; iod++)
1378 if (nfs_iodwant[iod]) {
1379 gotiod = TRUE;
1380 break;
1381 }
1382
1383 /*
1384 * Try to create one if none are free.
1385 */
1386 if (!gotiod) {
1387 iod = nfs_nfsiodnew();
1388 if (iod != -1)
1389 gotiod = TRUE;
1390 }
Let's consider situation when new nfsiod is created.
nfs_nfsiod.c:nfs_nfsiodnew() before creating nfssvc_iod thread unlocks
nfs_iod_mtx:
179 mtx_unlock(nfs_iod_mtx);
180 error = kthread_create(nfssvc_iod, nfs_asyncdaemon + i, NULL,
RFHIGHPID,
181 0, nfsiod %d, newiod);
182 mtx_lock(nfs_iod_mtx);
And nfs_nfsiod.c:nfssvc_iod() do the followin:
226 mtx_lock(nfs_iod_mtx);
...
238 nfs_iodwant[myiod] = curthread-td_proc;
239 nfs_iodmount[myiod] = NULL;
...
244 error = msleep(nfs_iodwant[myiod], nfs_iod_mtx, PWAIT
| PCATCH,
245 -, timo);
Let's at this moment another nfs_asyncio() request for another nfsmount has
happened and this thread has locked nfs_iod_mtx. Then this thread will found
nfs_iodwant[iod] in for loop and will use it. When the first thread actually
has returned from nfs_nfsiodnew() it will insert buffer to nmp-nm_bufq but
nfsiod will process other nmp.
Ok, good catch, I think you've found the problem (or at least a race
that might have caused it).
It looks like the fix for this situation would be to check nfs_iodwant[iod]
after nfs_nfsiodnew():
--- nfs_bio.c.orig 2010-01-22 15:38:02.0 +
+++ nfs_bio.c 2010-01-22 15:39:58.0 +
@@ -1385,7 +1385,7 @@ again:
*/
if (!gotiod) {
iod = nfs_nfsiodnew();
- if (iod != -1)
+ if ((iod != -1) (nfs_iodwant[iod] == NULL))
gotiod = TRUE;
}
Unfortunately, I don't think the above fixes the problem.
If another thread that called nfs_asyncio() has stolen the this iod,
it will have set nfs_iodwant[iod] == NULL (set non-NULL at #238)
and it will remain NULL until the other thread is done with it.
If you instead make it:
if (iod != -1 nfs_iodwant[iod] != NULL)
gotiod = TRUE;
then I think it fixes your scenario above, but will break for the
case where the mtx_lock(nfs_iod_mtx) call in nfs_nfsnewiod() (#182) wins
out over the one near the beginning of nfssvc_iod() (#226), since in that
case, nfs_iodwant[iod] will still be NULL because it hasn't yet been
set by nfssvc_iod() (#238).
There should probably be some sort of 3 way handshake between
the code in nfs_asyncio() after calling nfs_nfsnewiod() and the
code near the beginning of nfssvc_iod(), but I think the following
somewhat cheesy fix might do the trick:
if (!gotiod) {
iod = nfs_nfsiodnew();
if (iod != -1) {
if (nfs_iodwant[iod] == NULL) {
/*
* Either another thread has acquired this
* iod or I acquired the nfs_iod_mtx mutex
* before the new iod thread did in
* nfssvc_iod(). To be safe, go back and
* try again after allowing another thread
* to acquire the nfs_iod_mtx mutex.
*/
mtx_unlock(nfs_iod_mtx);
/*
* So long as mtx_lock() implements some
* sort of fairness, nfssvc_iod() should
* get nfs_iod_mtx here and set
* nfs_iodwant[iod] != NULL for the case
* where the iod has not been stolen by
* another thread for a different mount
* point.
*/
mtx_lock(nfs_iod_mtx);
goto again;
}
gotiod = TRUE;
}
Re: FreeBSD NFS client/Linux NFS server issue
On Fri, 22 Jan 2010 14:37:48 -0500 (EST) Rick Macklem wrote:
--- nfs_bio.c.orig 2010-01-22 15:38:02.0 +
+++ nfs_bio.c 2010-01-22 15:39:58.0 +
@@ -1385,7 +1385,7 @@ again:
*/
if (!gotiod) {
iod = nfs_nfsiodnew();
- if (iod != -1)
+ if ((iod != -1) (nfs_iodwant[iod] == NULL))
gotiod = TRUE;
}
Unfortunately, I don't think the above fixes the problem.
If another thread that called nfs_asyncio() has stolen the this iod,
it will have set nfs_iodwant[iod] == NULL (set non-NULL at #238)
and it will remain NULL until the other thread is done with it.
I see. I have missed this. Thanks.
There should probably be some sort of 3 way handshake between
the code in nfs_asyncio() after calling nfs_nfsnewiod() and the
code near the beginning of nfssvc_iod(), but I think the following
somewhat cheesy fix might do the trick:
if (!gotiod) {
iod = nfs_nfsiodnew();
if (iod != -1) {
if (nfs_iodwant[iod] == NULL) {
/*
* Either another thread has acquired this
* iod or I acquired the nfs_iod_mtx mutex
* before the new iod thread did in
* nfssvc_iod(). To be safe, go back and
* try again after allowing another thread
* to acquire the nfs_iod_mtx mutex.
*/
mtx_unlock(nfs_iod_mtx);
/*
* So long as mtx_lock() implements some
* sort of fairness, nfssvc_iod() should
* get nfs_iod_mtx here and set
* nfs_iodwant[iod] != NULL for the case
* where the iod has not been stolen by
* another thread for a different mount
* point.
*/
mtx_lock(nfs_iod_mtx);
goto again;
}
gotiod = TRUE;
}
}
Does anyone else have a better solution?
(Mikolaj, could you by any chance test this? You can test yours, but I
think it breaks.)
Unfortunately we observed this only on our production servers. A week ago we
made some changes in configuration as workaround -- reconfigure cron no to run
scripts simultaneously, set the scripts in cron that just periodically write a
line to the file on nfs share (to unlock it if it is locked). We have not
been observed problems since then and we would not like to experiment in
production. If I manage to produce good test case in test environment I will
be able to test the patch but I am not sure...
--
Mikolaj Golub
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD NFS client/Linux NFS server issue
On Fri, 22 Jan 2010, Rick Macklem wrote:
There should probably be some sort of 3 way handshake between
the code in nfs_asyncio() after calling nfs_nfsnewiod() and the
code near the beginning of nfssvc_iod(), but I think the following
somewhat cheesy fix might do the trick:
[stuff deleted]
I know it's a little weird to reply to my own posting, but I think
this might be a reasonable patch (I have only tested it for a few
minutes at this point).
I basically redefined nfs_iodwant[] as a tri-state variable (although
it was a struct proc *, it was only tested NULL/non-NULL).
0 - was NULL
1 - was non-NULL
-1 - just created by nfs_asyncio() and will be used by it
I'll keep testing it, but hopefully someone else can test and/or
review it... rick
ps: Mikolaj, I'm a sysadmin so I understand the problems with
production systems, but if you do get a chance to test it somehow,
that would be great.
pss: This is against -current, but hopefully stable/7 can be patched
about the same.
--- patch for nfsiod race against -current ---
--- nfsclient/nfs.h.sav 2010-01-22 16:21:53.0 -0500
+++ nfsclient/nfs.h 2010-01-22 16:22:04.0 -0500
@@ -252,7 +252,7 @@
intnfs_commit(struct vnode *vp, u_quad_t offset, int cnt,
struct ucred *cred, struct thread *td);
intnfs_readdirrpc(struct vnode *, struct uio *, struct ucred *);
-intnfs_nfsiodnew(void);
+intnfs_nfsiodnew(int);
intnfs_asyncio(struct nfsmount *, struct buf *, struct ucred *, struct
thread *);
intnfs_doio(struct vnode *, struct buf *, struct ucred *, struct thread *);
void nfs_doio_directwrite (struct buf *);
--- nfsclient/nfsnode.h.sav 2010-01-22 14:56:34.0 -0500
+++ nfsclient/nfsnode.h 2010-01-22 14:56:52.0 -0500
@@ -180,7 +180,7 @@
* Queue head for nfsiod's
*/
extern TAILQ_HEAD(nfs_bufq, buf) nfs_bufq;
-extern struct proc *nfs_iodwant[NFS_MAXASYNCDAEMON];
+extern int nfs_iodwant[NFS_MAXASYNCDAEMON];
extern struct nfsmount *nfs_iodmount[NFS_MAXASYNCDAEMON];
#if defined(_KERNEL)
--- nfsclient/nfs_bio.c.sav 2010-01-22 14:57:28.0 -0500
+++ nfsclient/nfs_bio.c 2010-01-22 16:17:24.0 -0500
@@ -1377,7 +1377,7 @@
* Find a free iod to process this request.
*/
for (iod = 0; iod nfs_numasync; iod++)
- if (nfs_iodwant[iod]) {
+ if (nfs_iodwant[iod] 0) {
gotiod = TRUE;
break;
}
@@ -1386,7 +1386,7 @@
* Try to create one if none are free.
*/
if (!gotiod) {
- iod = nfs_nfsiodnew();
+ iod = nfs_nfsiodnew(1);
if (iod != -1)
gotiod = TRUE;
}
@@ -1398,7 +1398,7 @@
*/
NFS_DPF(ASYNCIO, (nfs_asyncio: waking iod %d for mount %p\n,
iod, nmp));
- nfs_iodwant[iod] = NULL;
+ nfs_iodwant[iod] = 0;
nfs_iodmount[iod] = nmp;
nmp-nm_bufqiods++;
wakeup(nfs_iodwant[iod]);
--- nfsclient/nfs_nfsiod.c.sav 2010-01-22 14:57:28.0 -0500
+++ nfsclient/nfs_nfsiod.c 2010-01-22 16:32:31.0 -0500
@@ -113,7 +113,7 @@
* than the new minimum, create some more.
*/
for (i = nfs_iodmin - nfs_numasync; i 0; i--)
- nfs_nfsiodnew();
+ nfs_nfsiodnew(0);
out:
mtx_unlock(nfs_iod_mtx);
return (0);
@@ -147,7 +147,7 @@
*/
iod = nfs_numasync - 1;
for (i = 0; i nfs_numasync - nfs_iodmax; i++) {
- if (nfs_iodwant[iod])
+ if (nfs_iodwant[iod] 0)
wakeup(nfs_iodwant[iod]);
iod--;
}
@@ -160,7 +160,7 @@
Max number of nfsiod kthreads);
int
-nfs_nfsiodnew(void)
+nfs_nfsiodnew(int set_iodwant)
{
int error, i;
int newiod;
@@ -176,12 +176,17 @@
}
if (newiod == -1)
return (-1);
+ if (set_iodwant 0)
+ nfs_iodwant[i] = -1;
mtx_unlock(nfs_iod_mtx);
error = kproc_create(nfssvc_iod, nfs_asyncdaemon + i, NULL, RFHIGHPID,
0, nfsiod %d, newiod);
mtx_lock(nfs_iod_mtx);
- if (error)
+ if (error) {
+ if (set_iodwant 0)
+ nfs_iodwant[i] = 0;
return (-1);
+ }
nfs_numasync++;
return (newiod);
}
@@ -199,7 +204,7 @@
nfs_iodmin = NFS_MAXASYNCDAEMON;
for (i = 0; i nfs_iodmin; i++) {
- error = nfs_nfsiodnew();
+ error = nfs_nfsiodnew(0);
if (error == -1)
panic(nfsiod_setup: nfs_nfsiodnew failed);
}
@@ -236,7 +241,8 @@
goto finish;
if (nmp)
nmp-nm_bufqiods--;
- nfs_iodwant[myiod] = curthread-td_proc;
+ if
Re: FreeBSD NFS client/Linux NFS server issue
Hi, In this thread I have posted to freebsd-fs@ several messages describing our problem with freebsd7.1 nfs clients. As with the time new info has appeared and having this all spread in several messages might be a bit confusing, I want to summarise here what we see and know. Also I cc to freebsd-stable@ hoping to draw more attention to this problem as it looks for me very interesting and challenging :-) I have found in the Internet that other people have been observed the similar problem with FreeBSD6.2 client: http://forums.freebsd.org/showthread.php?t=1697 So, on some of our freebsd7.1 nfs clients (and it looks like we have had similar case with 6.3), which have several nfs mounts to the same CentOS 5.3 NFS server (mount options: rw,-3,-T,-s,-i,-r=32768,-w=32768,-o=noinet6), at some moment the access to one of the NFS mount gets stuck, while the access to the other mounts works ok. In all cases we have been observed so far the first gotten stuck process was php script (or two) that was (were) writing to logs file (appending). In tcpdump we see that every write to the file causes the sequence of the following rpc: ACCESS - READ - WRITE - COMMIT. And at some moment this stops after READ rpc call and successful reply. After this in tcpdump successful readdir/access/lookup/fstat calls are observed from our other utilities, which just check the presence of some files and they work ok (df also works). The php process at this state is in bo_wwait invalidating buffer cache [1]. If at this time we try accessing the share with mc then it hangs acquiring the vn_lock held by php process [2] and after this any operations with this NFS share hang (df hangs too). If instead some other process is started that writes to some other file on this share (append) then the first process unfreezes too (starting from WRITE rpc, so there is no any retransmits). With my limited knowledge of this complicated kernel subsystem I have the following hypothesis what is going on. On some of the nfs_write() it does successful ACCESS - READ rpcs but by some reason does not call WRITE to flush dirty buffer to the server (aborts somewere or may be in bdwrite() which calls bd_wakeup() and actually bd_wakeup considers that we don't have enough dirty buffers?). But it looks like on this stage the buffer appears to be unlinked from bufqueues [3] so when bufdaemon runs it does not flush the buffer. The next write() call to this file causes the process to get stuck invalidating the dirty buffer. The buffer is accessible by nfsiod via nmp structure [3] and when the next process is writing to another file, nfsiod is started and flushes this dirty buffer. [1]: Gotten stuck php process: (kgdb) bt #0 sched_switch (td=0xc839e000, newtd=Variable newtd is not available. ) at /usr/src/sys/kern/sched_ule.c:1944 #1 0xc07cabe6 in mi_switch (flags=Variable flags is not available. ) at /usr/src/sys/kern/kern_synch.c:440 #2 0xc07f42fb in sleepq_switch (wchan=Variable wchan is not available. ) at /usr/src/sys/kern/subr_sleepqueue.c:497 #3 0xc07f460c in sleepq_catch_signals (wchan=0xc90c9ee8) at /usr/src/sys/kern/subr_sleepqueue.c:417 #4 0xc07f4ebd in sleepq_wait_sig (wchan=0xc90c9ee8) at /usr/src/sys/kern/subr_sleepqueue.c:594 #5 0xc07cb047 in _sleep (ident=0xc90c9ee8, lock=0xc90c9e8c, priority=333, wmesg=0xc0b731ed bo_wwait, timo=0) at /usr/src/sys/kern/kern_synch.c:224 #6 0xc0827295 in bufobj_wwait (bo=0xc90c9ec4, slpflag=256, timeo=0) at /usr/src/sys/kern/vfs_bio.c:3870 #7 0xc0966307 in nfs_flush (vp=0xc90c9e04, waitfor=1, td=0xc839e000, commit=1) at /usr/src/sys/nfsclient/nfs_vnops.c:2989 #8 0xc09667ce in nfs_fsync (ap=0xed3c38ec) at /usr/src/sys/nfsclient/nfs_vnops.c:2725 #9 0xc0aee5d2 in VOP_FSYNC_APV (vop=0xc0c2b920, a=0xed3c38ec) at vnode_if.c:1007 #10 0xc0827864 in bufsync (bo=0xc90c9ec4, waitfor=1, td=0xc839e000) at vnode_if.h:538 #11 0xc083f354 in bufobj_invalbuf (bo=0xc90c9ec4, flags=1, td=0xc839e000, slpflag=256, slptimeo=0) at /usr/src/sys/kern/vfs_subr.c:1066 #12 0xc083f6e2 in vinvalbuf (vp=0xc90c9e04, flags=1, td=0xc839e000, slpflag=256, slptimeo=0) at /usr/src/sys/kern/vfs_subr.c:1142 #13 0xc094f216 in nfs_vinvalbuf (vp=0xc90c9e04, flags=Variable flags is not available. ) at /usr/src/sys/nfsclient/nfs_bio.c:1326 #14 0xc0951825 in nfs_write (ap=0xed3c3bc4) at /usr/src/sys/nfsclient/nfs_bio.c:918 #15 0xc0aef956 in VOP_WRITE_APV (vop=0xc0c2b920, a=0xed3c3bc4) at vnode_if.c:691 #16 0xc0850097 in vn_write (fp=0xc9969b48, uio=0xed3c3c60, active_cred=0xcb901600, flags=0, td=0xc839e000) at vnode_if.h:373 #17 0xc07f9d17 in dofilewrite (td=0xc839e000, fd=6, fp=0xc9969b48, auio=0xed3c3c60, offset=-1, flags=0) at file.h:256 #18 0xc07f9ff8 in kern_writev (td=0xc839e000, fd=6, auio=0xed3c3c60) at /usr/src/sys/kern/sys_generic.c:401 #19 0xc07fa06f in write (td=0xc839e000, uap=0xed3c3cfc) at /usr/src/sys/kern/sys_generic.c:317 #20 0xc0ad9c75 in syscall (frame=0xed3c3d38) at
Re: FreeBSD NFS client/Linux NFS server issue
On Tue, 19 Jan 2010 10:02:57 +0200 Mikolaj Golub wrote: I have found in the Internet that other people have been observed the similar problem with FreeBSD6.2 client: http://forums.freebsd.org/showthread.php?t=1697 Reading this through carefully it looks like the guy did not experience the problem (gotten stuck processes). He just described the behaviour of freebsd client when appending the file. -- Mikolaj Golub ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
