All of lore.kernel.org
 help / color / mirror / Atom feed
From: Craig Dunwoody <cdunwoody@graphstream.com>
To: Sage Weil <sage@newdream.net>
Cc: cdunwoody@graphstream.com, ceph-devel@lists.sourceforge.net
Subject: Re: End to end data integrity checking in Ceph?
Date: Mon, 22 Mar 2010 10:24:46 -0700	[thread overview]
Message-ID: <5892.1269278686@n20.hq.graphstream.com> (raw)
In-Reply-To: Your message of "Mon, 22 Mar 2010 09:58:18 PDT." <Pine.LNX.4.64.1003220938310.21746@cobra.newdream.net>


Hello Sage,

sage writes:
>The ceph transport layer does a crc32c over all data that passes over the 
>wire to catch bit flips from the network (TCP's checksumming isn't very 
>strong).  This isn't truly end-to-end protection, though, as bit flips on 
>the client after the applicate write(2) but before writeback starts, or on 
>the server after receiving the message won't be detected.
>
>Btrfs does do it's own checksumming, so in theory if we match the function 
>on the client we can do better.  There is also some end-to-end data 
>integrity infrastructure in the kernel that IIRC Martin Peterson was 
>working on.  Much that is in the block layer, though; the only parts that 
>would be useful to ceph would relate to the userspace interface and page 
>cache.  I'm not sure what the current state of that work is.
>
>It would be nice to see end-to-end protection (complete with some sort of 
>userspace api) in action on a local file system (probably btrfs, which 
>actually stores checksums) as a model before trying to build it into a 
>more complicated distributed file system...

Thanks very much for this info.  Good to know that Ceph currently does
checking at network-transport level beyond what TCP does, and makes sense
to me that a local-FS implementation of end to end protection facilities
could be a next-step preceding distributed-FS implementation.

Craig Dunwoody
GraphStream Incorporated

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev

      reply	other threads:[~2010-03-22 17:24 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-21 20:22 End to end data integrity checking in Ceph? Craig Dunwoody
2010-03-22 16:58 ` Sage Weil
2010-03-22 17:24   ` Craig Dunwoody [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5892.1269278686@n20.hq.graphstream.com \
    --to=cdunwoody@graphstream.com \
    --cc=ceph-devel@lists.sourceforge.net \
    --cc=sage@newdream.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.