cepted,
> > > I would like this to go in.
> >
> > It should be fine still.
>
> Great.
>
> Asking Scott permission before I MFC - the change in question is
> nfsclient/nfs_socket.c:1.138.
> This is an important fix that fixes potential data corruptions, very frequen
t.
Asking Scott permission before I MFC - the change in question is
nfsclient/nfs_socket.c:1.138.
This is an important fix that fixes potential data corruptions, very frequent
NFS/TCP
disconnects and the like.
I will MFC to releng_6 once you OK it.
mohan
_
On Sat, Sep 30, 2006 at 06:42:02PM -0700, Mohan Srinivasan wrote:
> I thought I had MFC'ed the fix to releng_6. Maybe I did not :(. Sorry...
>
> I don't know if it is too late to get this into 6.1 or not. cc:ing re: for
> his comments.
> This is a pretty serious bug, and if there are last minute
I don't know if mohan already committed it, so perhaps he can comment.
>
> Kris
>
> On Fri, Sep 29, 2006 at 10:10:02AM +0200, Yuri Khotyaintsev wrote:
> > Will a fix for NFS/TCP (nfs_socket.c rev 1.138) be ever committed to stable?
> >
> > Yuri Khotyaint
I don't know if mohan already committed it, so perhaps he can comment.
Kris
On Fri, Sep 29, 2006 at 10:10:02AM +0200, Yuri Khotyaintsev wrote:
> Will a fix for NFS/TCP (nfs_socket.c rev 1.138) be ever committed to stable?
>
> Yuri Khotyaintsev wrote:
> >On Monday 08
Will a fix for NFS/TCP (nfs_socket.c rev 1.138) be ever committed to stable?
Yuri Khotyaintsev wrote:
On Monday 08 May 2006 19:41, Kris Kennaway wrote:
On Mon, May 08, 2006 at 01:54:58PM +0200, Yuri Khotyaintsev wrote:
I have an NSF server and several clients which write large text
On Monday 08 May 2006 19:41, Kris Kennaway wrote:
> On Mon, May 08, 2006 at 01:54:58PM +0200, Yuri Khotyaintsev wrote:
> > I have an NSF server and several clients which write large text files to
> > the server. All machines are running max one week old STABLE and are
> > connected to the same giga
On Mon, May 08, 2006 at 01:54:58PM +0200, Yuri Khotyaintsev wrote:
> I have an NSF server and several clients which write large text files to the
> server. All machines are running max one week old STABLE and are connected to
> the same gigabit switch, and have identical nics (em). Amd mount opti
I have an NSF server and several clients which write large text files to the
server. All machines are running max one week old STABLE and are connected to
the same gigabit switch, and have identical nics (em). Amd mount options are:
/defaults
type:=nfs;cache:=all;opts:=rw,intr,nosuid,grpid,nfsv
On Thu, May 26, 2005 at 02:37:35PM +0200, Sten Spans wrote:
> On Thu, 26 May 2005, Bernd Walter wrote:
>
> >>>
> >>>This is absolutely known - TCP/nfs has bugs in realigning packets.
> >>>Don't use TCP on strong aligned architectures.
> >>
> >>Still a pr with a proper backtrace would be nice.
> >>
On Thu, 26 May 2005, Bernd Walter wrote:
This is absolutely known - TCP/nfs has bugs in realigning packets.
Don't use TCP on strong aligned architectures.
Still a pr with a proper backtrace would be nice.
Or does one exist already ?
Not that I know.
I did know exactly when this happens year
On Thu, May 26, 2005 at 12:45:50PM +0200, Sten Spans wrote:
> On Thu, 26 May 2005, Bernd Walter wrote:
>
> >On Thu, May 26, 2005 at 01:03:25AM +0200, Oliver Lehmann wrote:
> >>##
> >>
> >>
> >>I tried the same with an other nfs server (using dill as nfs server this
> >>time - system descriptio
On Thu, 26 May 2005, Bernd Walter wrote:
On Thu, May 26, 2005 at 01:03:25AM +0200, Oliver Lehmann wrote:
##
I tried the same with an other nfs server (using dill as nfs server this
time - system description is in my 1st mail, same mount options like /
mnt/files). And guess what? dill rebo
Oliver Lehmann wrote:
> Hi Mohan,
>
> Mohan Srinivasan wrote:
>
>
> > Is this consistently reproducible ?
>
> it is - everytime
I found out that I can reproducible make it work by writing on an other
harddisk.
file:/mnt/files 151368706 109165638 30093572 78% /mnt/files
file:/usr/ports
On Thu, May 26, 2005 at 01:03:25AM +0200, Oliver Lehmann wrote:
> ##
>
>
> I tried the same with an other nfs server (using dill as nfs server this
> time - system description is in my 1st mail, same mount options like /
> mnt/files). And guess what? dill rebooted immediate... dd came never
>
time - system description is in my 1st mail, same mount options like /
mnt/files). And guess what? dill rebooted immediate... dd came never
back, gave no output
Just for a data point here - I have a 5.3-STABLE (from about January
15th) that is serving up data via NFS (tcp and udp, FreeBSD, Li
Oliver Lehmann wrote:
> So.. using i386 as an tcp nfs-server - the only thing which happens is
> that dd gets interruped, using alpha as an tcp nfs-server makes the alpha
> panic.
Ok, maybe the alpha has other problems... Disk worked for 7 years without
problems but I just rebooted the system onc
Hi Mohan,
Mohan Srinivasan wrote:
> Is this consistently reproducible ?
it is - everytime
> I tried reproducing this with this morning's
> current,
it also happens with STABLE
> How big was your file that you tried to dd ? I need to reproduce this here
> in order to track it down.
dd if=/
sec)
Exit 1
dmesg gives me "nfs send error 35 for server file:/mnt/files"
fstab entry on kartoffel and dill:
file:/mnt/files /mnt/files nfs tcp,nfsv3,soft,bg,rw,noauto 0 0
- kartoffel is an amd64 system with an onboard re0
running CURRENT from May 24th evening.
- dill
19 matches
Mail list logo
