>>That might work for XFS but it won't work for the wider Ceph cluster — >>it's against the RADOS guarantees and expectations for an OSD to go >>back in time after committing an update and *can* result in failure. >>-Greg But we have osd journals (sync writes) and it should replay on failure ? ----- Mail original ----- De: "Dan Jakubiec" <dan.jakubiec@xxxxxxxxx> À: "Nathan Cutler" <ncutler@xxxxxxx> Cc: "ceph-devel" <ceph-devel@xxxxxxxxxxxxxxx> Envoyé: Jeudi 1 Décembre 2016 17:04:32 Objet: Re: What is XFS/filesystem corruption and whose fault is it? We lost a whole cluster once due to incorrect write cache settings on multiple OSDs. I think the recommendations on that page are correct, but I would also add that you must disable any write caching on the drive itself as well. The XFS FAQ is the best place I've found that explains all the ins and outs (Q24 thru Q28): http://xfs.org/index.php/XFS_FAQ <http://xfs.org/index.php/XFS_FAQ> -- Dan > On Nov 25, 2016, at 10:26, Nathan Cutler <ncutler@xxxxxxx> wrote: > > I've been doing some research on OSDs not starting after power outages, when supposedly "uncorruptible" XFS filesystems are corrupted and need repair. This led me to write the following brief blog post: > > http://smithfarm-thebrain.blogspot.cz/2016/11/what-is-xfsfilesystem-corruption-and.html > > Any comments and/or suggestions for improvement would be most welcome. > > Thanks for reading! > > Nathan > -- > To unsubscribe from this list: send the line "unsubscribe ceph-devel" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
