Linux-kernel mailing list archive 1999-37,: Re: NFS corruption revisited

# Re: NFS corruption revisited

David Weinehall (tao@acc.umu.se)
Wed, 15 Sep 1999 17:36:01 +0200 (MET_DST)

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Alan Cox: "Re: NFS corruption revisited"
- Previous message: Tigran Aivazian: "[q] signal_map still needed in struct exec_domain?"
- In reply to: Alan Cox: "Re: NFS corruption revisited"
- Next in thread: Trond Myklebust: "Re: NFS corruption revisited"

On Wed, 15 Sep 1999, Alan Cox wrote:

> > The following is a ethereal dump of the NFS traffic for the particular
> > bytes above:
> >
> > packet #303:
> > 04b0 89 c0 50 8d 93 f0 fe ff ff 89 d0 50 8b 93 4c 00 ..P........P..L.
> > 04c0 00 00 89 d0 50 e8 ae e6 ff ff 83 c4 0c 8d 93 07 ....P...........
> > 04d0 ff ff ff 89 00 00 ......
> > ^^^^^
>
> That looks fine.
>
> > If additional data is required, please let me know.
>
> You need tcpdump data with the rpc fully decoded. Padding rpc's is quite
> valid and that is what the trace shows I believe.

Yes, but it is this padding that causes the problems (Sun's nfsd ignores
the packet-size field and supposes (packet-length - header) to be the real
size).

> How close are AIX and Solaris nfsd I wonder

They *should* be a re-compile apart, approximately (+/- a few
optimisations, maybe.)

/David
_ _
// David Weinehall <tao@acc.umu.se> /> Northern lights wander \\
// Project MCA Linux hacker // Dance across the winter sky //
\> http://www.acc.umu.se/~tao/ </ Full colour fire </

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

- Next message: Alan Cox: "Re: NFS corruption revisited"
- Previous message: Tigran Aivazian: "[q] signal_map still needed in struct exec_domain?"
- In reply to: Alan Cox: "Re: NFS corruption revisited"
- Next in thread: Trond Myklebust: "Re: NFS corruption revisited"