Subject: RE: [nfsv4] Extensions to NFSv4 for Checksums

From: "Everhart, Craig" <[email-masked]>
Date: Fri, 10 Feb 2006 17:24:26 -0500

In reply to Ric Werme's message of 10 Feb, 4:41pm: 
> 
> Perhaps "without returning checksum data"?  You're implying 
> that if the server keeps checksum data as part of the file's 
> metadata, then in this case the server would not do its own 
> checks.  (I assume a checksum error found within the file 
> system turns into an I/O error in all cases.)
> 
> Wouldn't it be simpler to allow clients to send READ and not 
> follow it with CKSUM?

My guess is that it would be better to precede the READ and
WRITE both with the CKSUM, rather than having it follow the
READ, so that the server can know whether it should bother
computing a checksum on the data as it passes through.
If the client didn't want the checksum, it wouldn't use the
CKSUM operator.

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: "Everhart, Craig" <[email-masked]>
Date: Fri, 10 Feb 2006 17:29:03 -0500

Argh.  My bad.  I forgot that CKSUM is basically INOUT, so
that the READ wants to return the CKSUM result after the
READ has happened.  Now, if there were two ops, one to request
a checksum and one to load that result, then the READ could
happen between them, and that would prevent the READ processor
from having to look ahead to see whether the checksum was going
to be requested.  Or, if once checksum processing is turned on
it's expected most always to be on, then one could do as
Ric suggests and not request the computed result.

		Craig 

> -----Original Message-----
> From: Everhart, Craig 
> Sent: Friday, February 10, 2006 5:24 PM
> To: 'Eric Werme USG'; Alok Aggarwal
> Cc: [email-masked]
> Subject: RE: [nfsv4] Extensions to NFSv4 for Checksums 
> 
> > Perhaps "without returning checksum data"?  You're implying that if 
> > the server keeps checksum data as part of the file's 
> metadata, then in 
> > this case the server would not do its own checks.  (I assume a 
> > checksum error found within the file system turns into an 
> I/O error in 
> > all cases.)
> > 
> > Wouldn't it be simpler to allow clients to send READ and 
> not follow it 
> > with CKSUM?
>

---

From: Jim Rees <[email-masked]>
Date: Mon, 13 Feb 2006 22:02:12 -0500

iSCSI started out with implementing Adler32 but they eventually
  settled on CRC32. There's no reason why NFS can't pick CRC32 as well.

I know at least one v4 user who claims that crc32 isn't good enough and that
he wants crc64.