On 16-12-01 20:52, Alexandre DERUMIER wrote:
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 ?
if data gets to xfs it means it was flushed from the journal and Ceph
thinks that data is safe on filesystem, so it is very likely that this
data will not be present in journals anymore
----- 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
