I ask this because in a previous installation where I was running 1TB of RAID1 (2 disks) under Centos 5, I noticed that after a few days the RAID disk would go into readonly mode. When I unmounted it and rand a disk check (fsck) it reported a whole bunch of errors of shared nodes, etc, all which it fixed. However, after putting the disk back online the same problem occurred a couple of days later. I checked the RAID disks independently for bad blocks, etc and one of them was reporting some errors which were fixed. In the end I had to replace the disk that kept reporting some errors, even though I was told that they were fixed. When I did this, I no longer had the problem. So you can see what I'm trying to understand how gluster might deal with such a case, if errors occurring in one of the replicated nodes would find its way into the other nodes and corrupt them. John On Fri, Jul 9, 2010 at 10:37 PM, Emmanuel Noobadmin <centos.admin at gmail.com>wrote: > On 7/8/10, John Preston <byhisdeeds at gmail.com> wrote: > > I am setting up a gluster configuration to replicate data across 3 nodes > > using: > > > > volume afr-volume > > type cluster/replicate > > subvolumes brick1 brick2 brick3 > > end-volume > > > > Can someone say what safeguards exist with such a configuration to ensure > > that if one of the nodes disks, starts to go bad and thus introduce > errors > > in one or more of the copies of files, that these bad sectors don't get > > replicated across the cluster. > > I'm not certain but if the disk develops hard problems, I'll assume > the host node will report it as an IO error and therefore the node is > considered as failed? I suppose the problem would be if the node > manages to read "something" after a retry. > > Just giving my 2cents and hoping to stir up some interest in this :) > _______________________________________________ > Gluster-users mailing list > Gluster-users at gluster.org > http://gluster.org/cgi-bin/mailman/listinfo/gluster-users >
