Hi,
starting about last week, I'm getting:
rsync: writefd_unbuffered failed to write 4 bytes to socket [sender]: Broken
pipe (32)
rsync: write failed on /net/rnd/dist/tmp/local/amd64.FreeBSD_8.3-wip/compat/li
nux/usr/lib/locale/locale-archive.tmpl: Permission denied (13)
rsync error: error in
Hi,
starting about last week, I'm getting:
rsync: writefd_unbuffered failed to write 4 bytes to socket [sender]: Broken
pipe (32)
rsync: write failed on
/net/rnd/dist/tmp/local/amd64.FreeBSD_8.3-wip/compat/li
nux/usr/lib/locale/locale-archive.tmpl: Permission denied (13)
rsync error:
On 29/06/2012 10:45, Daniel Braniss wrote:
Hi,
starting about last week, I'm getting:
rsync: writefd_unbuffered failed to write 4 bytes to socket [sender]: Broken
pipe (32)
rsync: write failed on
/net/rnd/dist/tmp/local/amd64.FreeBSD_8.3-wip/compat/li
On 29/06/2012 10:45, Daniel Braniss wrote:
Hi,
starting about last week, I'm getting:
rsync: writefd_unbuffered failed to write 4 bytes to socket [sender]:
Broken
pipe (32)
rsync: write failed on
/net/rnd/dist/tmp/local/amd64.FreeBSD_8.3-wip/compat/li
Lev Serebryakov wrote:
You see? b answer with UDP port unreachable on each RPC reply!
Additional info.
ktrace from mount -t nfs:
=
65962 mount_nfs 0.006679 RET sendto 40/0x28
65962 mount_nfs 0.006682 CALL
Lev Serebryakov wrote:
Main problem is, that /etc/fstab is processed by mount, and NFS
mount hangs up on boot, as shown above :(
Mounting with mount -t nfs with 7.0 server (host B) and 6.3 client
(host A) works...
--
// Lev Serebryakov
___
Hello, freebsd-stable.
You wrote 16 мая 2008 г., 14:40:18:
There is NO any firewalls on B. And, I repeat, it WORKS when I call
mount_nfs directly in a moment!
Adding `-o -c' to mount (to pass `-c' to mount_nfs) helps. But I'm
very curious WHY mount_nfs, called directly, work WITHOUT `-c'...
I upgraded 9 of my systems to RELENG_5 on Oct 29 and 30. Now none of them
can do a dump to an NFS mounted directory.
the NFS connection is made, because the dump file is created on the NFS
directory, but it stays at 0 bytes.
The system that is doing the dump hangs after:
oregon root:#dump
- Original Message -
From: Elliot Finley [EMAIL PROTECTED]
I upgraded 9 of my systems to RELENG_5 on Oct 29 and 30. Now none of them
can do a dump to an NFS mounted directory.
Oops I also changed some ipf rules and after opening everything up, the
dump works again.
Sorry for the
Jon Dama wrote:
Try switching to TCP NFS.
a 100MBit interface cannot keep up with a 1GBit interface in a bridge
configuration. Therefore, in the long run, at full-bore you'd expect to
drop 9 out of every 10 ethernet frames.
MTU is 1500 therefore 1K works (it fits in one frame), 2K doesn't
Jon Dama wrote:
Try switching to TCP NFS.
a 100MBit interface cannot keep up with a 1GBit interface in a bridge
configuration. Therefore, in the long run, at full-bore you'd expect to
drop 9 out of every 10 ethernet frames.
MTU is 1500 therefore 1K works (it fits in one frame), 2K doesn't
Yes, but surely you weren't bridging gigabit and 100Mbit before?
Did you try my suggestion about binding the IP address of the NFS server
to the 100Mbit side?
-Jon
On Tue, 31 May 2005, Skylar Thompson wrote:
Jon Dama wrote:
Try switching to TCP NFS.
a 100MBit interface cannot keep up
Yes, but surely you weren't bridging gigabit and 100Mbit before?
Did you try my suggestion about binding the IP address of the NFS server
to the 100Mbit side?
-Jon
On Tue, 31 May 2005, Skylar Thompson wrote:
Jon Dama wrote:
Try switching to TCP NFS.
a 100MBit interface cannot keep up
Jon Dama wrote:
Yes, but surely you weren't bridging gigabit and 100Mbit before?
Did you try my suggestion about binding the IP address of the NFS server
to the 100Mbit side?
Yeah. Unfortunately networking on the server fell apart when I did that.
Traffic was still passed and I could
Jon Dama wrote:
Yes, but surely you weren't bridging gigabit and 100Mbit before?
Did you try my suggestion about binding the IP address of the NFS server
to the 100Mbit side?
Yeah. Unfortunately networking on the server fell apart when I did that.
Traffic was still passed and I could
Oh, something else to try:
I checked through my notes and discovered that I had gotten UDP to work in
a similar configuration before. What I did was bind the IP address to
fxp0 instead of em0. By doing this, the kernel seems to send the data at
a pace suitable for the slow interface.
-Jon
Oh, something else to try:
I checked through my notes and discovered that I had gotten UDP to work in
a similar configuration before. What I did was bind the IP address to
fxp0 instead of em0. By doing this, the kernel seems to send the data at
a pace suitable for the slow interface.
-Jon
On 26 May, Skylar Thompson wrote:
I'm having some problems with NFS serving on a FreeBSD 5.4-RELEASE
machine. The FreeBSD machine is the NFS/NIS server for a group of four
Linux clusters. The network archictecture looks like this:
234/24
On 26 May, Skylar Thompson wrote:
I'm having some problems with NFS serving on a FreeBSD 5.4-RELEASE
machine. The FreeBSD machine is the NFS/NIS server for a group of four
Linux clusters. The network archictecture looks like this:
234/24
Try switching to TCP NFS.
a 100MBit interface cannot keep up with a 1GBit interface in a bridge
configuration. Therefore, in the long run, at full-bore you'd expect to
drop 9 out of every 10 ethernet frames.
MTU is 1500 therefore 1K works (it fits in one frame), 2K doesn't (your
NFS
Try switching to TCP NFS.
a 100MBit interface cannot keep up with a 1GBit interface in a bridge
configuration. Therefore, in the long run, at full-bore you'd expect to
drop 9 out of every 10 ethernet frames.
MTU is 1500 therefore 1K works (it fits in one frame), 2K doesn't (your
NFS
I'm having some problems with NFS serving on a FreeBSD 5.4-RELEASE
machine. The FreeBSD machine is the NFS/NIS server for a group of four
Linux clusters. The network archictecture looks like this:
234/24 234/24
Cluster 1 ---
Already running the card and switch port in 100BaseTX FDX (forced) :)
Would use GigE if the switch supported it tho
Thus spake Matthew Dillon ([EMAIL PROTECTED]) :
It should also work if you force the GigE card into 100BaseTX mode,
assuming the switch can deal with it. Though
Hi folks,
I will do some more research on this problem myself tomorrow (it's fairly
late here), but I thought I might already post a message about this today:
From what I have read, the fixes to the NFS problems that Jordan mentioned
at the beginning of last week are by now in RELENG_4. However
I actually wanted to go to bed after posting my 4.5-PRE NFS problems
message, however, before I actually did that I ran a fsck on the NFS server
from which the filesystem causing the problems gets exported.
The fsck reported some inconsistencies (though the fs was not exactly
marked as dirty). I
Alfred Perlstein wrote:
* Pat Wendorf [EMAIL PROTECTED] [000925 10:13] wrote:
Hello All,
I've been using NFS on stable (3.x, 4.x) for a while now, and when it
works, it seems to be fast and reliable. However, I've noticed that in
any case where it doesn't work (nfs server goes down,
Hello All,
I've been using NFS on stable (3.x, 4.x) for a while now, and when it
works, it seems to be fast and reliable. However, I've noticed that in
any case where it doesn't work (nfs server goes down, cable gets
disconnected, weird network card driver issues, etc), the client
machines seem
* Pat Wendorf [EMAIL PROTECTED] [000925 10:13] wrote:
Hello All,
I've been using NFS on stable (3.x, 4.x) for a while now, and when it
works, it seems to be fast and reliable. However, I've noticed that in
any case where it doesn't work (nfs server goes down, cable gets
disconnected,
In message [EMAIL PROTECTED] Jaye Mathisen
writes:
: got bad cookie vp 0xd24bf1c0 bp 0xc9090500
: got bad cookie vp 0xd24bfda0 bp 0xc906ceb0
Seen these too. Not sure why. Too many other fire to fight.
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable"
29 matches
Mail list logo
