2011/7/28 Sage Weil <sage@xxxxxxxxxxxx>: > On Thu, 28 Jul 2011, huang jun wrote: >> 2011/7/28 Gregory Farnum <gregory.farnum@xxxxxxxxxxxxx>: >> > On Wed, Jul 27, 2011 at 9:05 AM, Gregory Farnum >> > <gregory.farnum@xxxxxxxxxxxxx> wrote: >> >> The doubled writes can be annoying, but it's really the only safe >> >> thing to do. Perhaps we could do something with btrfs and snapshots to >> >> avoid using a journal, but I'd have to look into it some more. >> > Actually this already works -- you are data safe if you run btrfs >> > without a journal. Apparently it's even slower, though -- you need to >> > go through a lot more syncs to guarantee your data safety. >> > >> we use btrfs and without journal, it turns out that : >> the performance of big write(10GB) is good, but the rm dir ops goes slow. >> So we reset the value of "filestore max sync interval = 0.1", the rm >> dirs rate increased. > > Do you mean the rate that the rm operations completed, or the lag before > the space became available? In general, a longer sync interval should > perform better (less fs commit overhead). > yes, the rm operation rate increased. we need 100s to remove 100 dirs if we set the value filestore max sync interval = 1.But now, we just need 13s to do the same. >> Does this related to version of ceph kernel Client and kernel ? Can we >> promote the DIR ops >> performance on OSD end? > > There shouldn't be any synchronous IO in the namespace operation paths > (except in odd situations involving multiple client interactions). > (Unless you fsync(dirfd), that is!) What latencies are you seeing? > > sage > > > >> > So your best bet if it's a real problem is to add a fast disk to use >> > as your journaling device. >> > >> -- >> 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
