Loss of the journal will kill any osds using that journal. With btrfs, we theoretically could run without a journal, but it would be impractically slow. In the case of parallel journaling, loss of the journal can result in the loss of updates which have been reported to the client as committed, but replacing the journal device will be enough to allow recovery from the replicas to occur. In the case of write ahead, loss of the journal can additionally result in inconsistent data on the osd. Thus, with write ahead, you should recreate the osd and allow recovery to occur. The --mkjournal option is used to recreate the journal on a fresh device. This information does need to find its way into our documentation, thanks for the heads up! -Sam On Fri, May 11, 2012 at 11:31 AM, Calvin Morrow <calvin.morrow@xxxxxxxxx> wrote: > The Ceph Wiki (http://ceph.com/wiki/OSD_journal) does a pretty good > job explaining the purpose of the journal and various modes available. > What isn't clear is what happens during the failure of a journal. > > With the use of btrfs enabling parallel journaling, it sounds like > failure of a journal device would still enable OSD writes to occur > albeit at a slower pace. In writeahead mode, failure of the journal > seems like it would take all OSDs using that device for journaling > offline. > > Is this a correct assessment? If the journal is a single point of > failure to a system with potentially multiple OSDs ... it might be > worth mentioning in one of the "building a cluster" or hardware pages > about journal redundancy. > > Also, it would be nice to know what steps are required to replace a > journal. (I think this is just an update of the cluster.conf with the > new journal device and a restart of the OSD process, correct?) > > Best regards, > Calvin > -- > 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
