Hi Nicheal,
Not only recovery , IMHO the main purpose of ceph journal is to support 
transaction semantics since XFS doesn't have that. I guess it can't be achieved 
with pg_log/pg_info.

Thanks & Regards
Somnath

-----Original Message-----
From: [email protected] 
[mailto:[email protected]] On Behalf Of ??
Sent: Tuesday, September 16, 2014 11:29 PM
To: [email protected]
Subject: puzzled with the design pattern of ceph journal, really ruining 
performance

Hi, guys

I analyze the architecture of the ceph souce code.

I know that, in order to keep journal atomic and consistent, the journal write 
mode should be set with O_DSYNC or called fdatasync() system call after every 
write operation. However, this kind of operation is really killing the 
performance as well as achieving high committing latency, even if SSD is used 
as journal disk. If the SSD has capacitor to keep the data safe when the system 
crashes, we can set the mount option nobarrier or SSD itself will ignore the 
FLUSH REQUEST. So the performance would be better.

So can it be instead by other strategies?
As far as I am concerned, I think the most important part is pg_log and 
pg_info. It will guides the crashed osd recovery its objects from the peers. 
Therefore, if we can keep pg_log at a consistent point, we can recovery data 
without journal. So can we just use an "undo"
strategy on pg_log and neglect ceph journal?  It will save lots of bandwidth, 
and also based on the consistent pg_log epoch, we can always recovery data from 
its peering osd, right? But this will lead to recovery more objects if the osd 
crash.

Nicheal
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the 
body of a message to [email protected] More majordomo info at  
http://vger.kernel.org/majordomo-info.html

________________________________

PLEASE NOTE: The information contained in this electronic mail message is 
intended only for the use of the designated recipient(s) named above. If the 
reader of this message is not the intended recipient, you are hereby notified 
that you have received this message in error and that any review, 
dissemination, distribution, or copying of this message is strictly prohibited. 
If you have received this communication in error, please notify the sender by 
telephone or e-mail (as shown above) immediately and destroy any and all copies 
of this message in your possession (whether hard copies or electronically 
stored copies).

N�����r��y����b�X��ǧv�^�)޺{.n�+���z�]z���{ay�ʇڙ�,j��f���h���z��w���
���j:+v���w�j�m��������zZ+�����ݢj"��!�i

Reply via email to