JM, OK, so what _is_ the correct place then. There is no rhss mailinglist on the redhat mailing list page <http://www.redhat.com/mailman/listinfo>... Anyways, I will repost in the gluster-devel mailing list Met vriendelijke groeten, * Fred van Zwieten * *Enterprise Open Source Services* * Consultant* *(vrijdags afwezig)* *VX Company IT Services B.V.* *T* (035) 539 09 50 mobiel (06) 41 68 28 48 *F* (035) 539 09 08 *E* fvzwieten at vxcompany.com *I* www.vxcompany.com On Mon, Jul 23, 2012 at 10:23 AM, John Mark Walker <johnmark at redhat.com>wrote: > Hi Fred, > > If you are interested in hearing more about RHSS, this really isn't the > right forum for it. > > However, if you would like to discuss creating a translator for GlusterFS, > we would love to talk to you. You should post this to the gluster-devel > mailing list - http://lists.nongnu.org/mailman/listinfo/gluster-devel > > Thanks, > JM > > > > > ----- Fred van Zwieten <fvzwieten at vxcompany.com> wrote: > > Hi there, > I am working for a customer right now who is considering Red Hat Storage > Server. One of the sought-after features there is bit-rot detection, and > even better, (semi-automatic) bit-rot restoration. > > > > I know RHSS (nor GlusterFS) has this kind of functionality at the moment > (correct me if i'm wrong!), but I would like to propose a design for this > as a sort of translator that can be stacked on i.e. a (geo) replication > translator. > > > > Bit-rot detection can be done through check-summing. It should be a very > low priority job running on one of the bricks. The job walks the complete > file system and, per file, calculates the check-sum, compares it with the > stored check-sum (if present, otherwise it stores the check-sum on all > involved bricks, because it hasn't been checked before). > > > > Bit-rot restoration could be implemented by comparing the check-sums of > the replicas. If there is a mismatch, a more thorough check must be > performed, like running a check-sum on all replica's for that file again, > do a bit-wise compare, or whatever. If the files are still the same, > the check-sum(s) must be replaced. If not, there is > actual bit-rot detected. Now what to do? Which replica holds the clean > version (the thruth?). With an uneven number of replicas one could simply > make it a democratic process and have it fully automated. It should however > save the to be replaced version in a separate store and notify the admin > for verification. Another method would be to just notify the admin and do > nothing. > > > > The obvious place to store the check-sums would be in the extended > attributes, but one could use a database for it. > > I have watch the presentation Red Hat Summit 2012 - A Deep Dive Into Red > Hat Storage<https://access.redhat.com/knowledge/videos/red-hat-summit-2012-deep-dive-red-hat-storage> by > Jeff Darcy and I know he (and Red Hat) are very keen on extending the > number of translators with useful functionality. I am no programmer myself, > but would like to get involved in this kind of stuff. > > > > Comments are very welcome! > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://gluster.org/pipermail/gluster-users/attachments/20120723/2f837c75/attachment.htm>
