Thank you for the great explanation Zheng! That definitely shows what I was seeing with the bonnie++ test. What bad things would happen if I modified the config option mds_tick_interval to flush the journal to a second or less? Does this also mean any custom code written should avoid use of fsync() if writing a large number of files? On Tue, May 26, 2015 at 9:30 AM, Gregory Farnum <greg@xxxxxxxxxxx> wrote: > On Tue, May 26, 2015 at 4:57 AM, John Spray <john.spray@xxxxxxxxxx> wrote: >> >> >> On 26/05/2015 07:55, Yan, Zheng wrote: >>> >>> the reason for slow file creations is that bonnie++ call fsync(2) after >>> each creat(2). fsync() wait for safe replies of the create requests. MDS >>> sends safe reply when log event for the request gets journaled safely. MDS >>> flush the journal every 5 seconds (mds_tick_interval). So the speed of file >>> creation for bonnie++ is one file every file seconds. >> >> >> Ah, I hadn't noticed that the benchmark called... I wonder if I'm seeing the >> fuse client return quickly because it simply doesn't implement the fsyncdir >> call. We should fix that! >> >> It looks like we used to have an OP_FSYNC in the client-server protocol >> (perhaps for flushing the log immediately on fsyncs), anyone have any >> background on why that went away? > > Following up, we discussed this in standup and the answer was "no". > > Seeing the question in context of this thread, though, I think maybe > I've asked before and either the answer or the deduced reason was > "because we didn't want to let clients force an (expensive) MDS log > flush". > -Greg -- 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
