On Wed, Feb 13, 2013 at 12:27 PM, Stefan Priebe <s.priebe@xxxxxxxxxxxx> wrote: > Hi, > > Am 13.02.2013 21:21, schrieb Sage Weil: > >>> This results in writes up to 400Mb/s per OSD and then results in aborted >>> / >>> hanging task in VMs. Is it possible to give trim commands lower priority? >> >> >> Is that 400Mb or MB? Measured over the network, or on the disk itself? > > > Sorry it's MB - so the SSDs get fully utilized meased via /proc/diskstats . > > >> I'm wondering if this is a lack of punch support on the kernel.. > > I'm using 3.7.7 running XFS. Sounds like maybe the client trim is ending up issuing a truly ridiculous number of truncate or trim operations from librbd to the OSDs? Like one for every RADOS block that could exist, or possibly even for each VM disk block? (Perhaps not; I'm not sure how trim got implemented.) FWIW a full fstrim is not generally an operation you can really do in the background even on a real desktop...so if running it one one or several VMs makes the cluster unusable for all of them, that's a problem, but if it only causes IO trouble for the one which is trimming that'd be not ideal but less of an issue. -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
