Hi, Personally I won't take the risk to loose transactions. If a client writes into a journal, assuming it's the first write and if the server crashs for whatever reason, you have high risk of un-consistent data. Because you just lost what was in the journal. Tmpfs is the cheapest solution for achieving better performance, but it's definitely not the most reliable. Keep in mind that you don't really want to see your load/data balancing through the cluster while recovering from a failure... At last resort, I will use the root filesystem if it's decently fast to store the journals. My 2 cents... Cheers! -- Bien cordialement. Sébastien HAN. On Wed, Oct 31, 2012 at 11:07 PM, Gandalf Corvotempesta <gandalf.corvotempesta@xxxxxxxxx> wrote: > > 2012/10/31 Stefan Kleijkers <stefan@xxxxxxxxxxxx>: > > As far as I know, this is correct. You get a ACK (on the write) back after > > it landed on ALL three journals (or/and osds in case of BTRFS in parallel > > mode). So If you lose one node, you still have it in two more nodes and they > > will commit it to disk. After recovering the missing node/osd it will get > > the data from one of the other nodes. So you won't lose any data. > > Sounds perfect, this will allow me to avoid SSD disks and using al 12 > disks on a DELL R515 as OSD > -- > 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
