> 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
>> nux/usr/lib/locale/l
> 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)
> rsyn
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 f
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'..
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
___
f
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
kevent(0x4,0x638
I have two hosts: host A (FreeBSD 6.3-S) and host B (FreeBSD 7.0-S,
freshly installed).
Host A exports "/usr/ports" to host B via NFS.
Mount with "mount_nfs" works well:
b# mount_nfs a:/usr/ports /usr/ports
b# ls /usr/ports
[---SKIPPED---=
b#
But mount with "mount -t nfs" FAILS:
b#
- 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 fo
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 -0au
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 g
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 g
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
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
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 (yo
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 (yo
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
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
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 transactions
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 transactions
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
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
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
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.
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 serv
* 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
> disconnecte
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
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"
UDP v2 mounts, Netapp Filer.
Getting a fair # of:
got bad cookie vp 0xd24bf1c0 bp 0xc9090500
got bad cookie vp 0xd24bfda0 bp 0xc906ceb0
on the console, and it seems to lock the machine up for several minutes
when it does. Then it comes back to life, and cranks for a while...
Not sure where
Dear -stable Users,
I would greatly appreciate any help with the following problem. I have a FreeBSD
NFS server (3.2-STABLE, built on Aug 3), and a Solaris 2.7 client.
I run into problems when trying to use NFSv3 mounts on the client. Trying to remove
files from the mounted partition (on the
32 matches
Mail list logo
