From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Zafman Subject: Re: deleting objects from a pool Date: Thu, 25 Jun 2015 18:45:37 -0700 Message-ID: <558CAEC1.3050204@redhat.com> References: <90559C83A9C7FA45B5846C975DFA612DDB4C3F7250@ABGEX73E.FSC.NET> <66EBB02ADA308B4F8273E99FC000126C6BEA0BD5C8@ABGEX70E.FSC.NET> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: Received: from mx1.redhat.com ([209.132.183.28]:47965 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751426AbbFZBpj (ORCPT ); Thu, 25 Jun 2015 21:45:39 -0400 In-Reply-To: <66EBB02ADA308B4F8273E99FC000126C6BEA0BD5C8@ABGEX70E.FSC.NET> Sender: ceph-devel-owner@vger.kernel.org List-ID: To: "Podoski, Igor" , "Deneau, Tom" , =?ISO-8859-2?Q?=22Da=B3ek=2C_Piotr=22?= , ceph-devel If you have rados bench data around, you'll need to run cleanup a secon= d=20 time because the first time the "benchmark_last_metadata" object will be consulted to find what objects to remove. Also, using cleanup this way will only remove objects from the default=20 namespace unless a namespace is specified with the -N option. rados -p -N cleanup --prefix "" David On 6/24/15 11:06 PM, Podoski, Igor wrote: > Hi, > > It appears, that cleanup can be used as a purge: > > rados -p cleanup --prefix "" > > Regards, > Igor. > > > -----Original Message----- > From: ceph-devel-owner@vger.kernel.org [mailto:ceph-devel-owner@vger.= kernel.org] On Behalf Of Deneau, Tom > Sent: Wednesday, June 24, 2015 10:22 PM > To: Da=B3ek, Piotr; ceph-devel > Subject: RE: deleting objects from a pool > > I've noticed that deleting objects from a basic k=3D2 m=3D1 erasure p= ool is much much slower than deleting a similar number of objects from = a replicated size 3 pool (so the same number of files to be deleted). = It looked like the ec pool object deletion was almost 20x slower. Is = there a lot more work to be done to delete an ec pool object? > > -- Tom > > > >> -----Original Message----- >> From: ceph-devel-owner@vger.kernel.org [mailto:ceph-devel- >> owner@vger.kernel.org] On Behalf Of Dalek, Piotr >> Sent: Wednesday, June 24, 2015 11:56 AM >> To: ceph-devel >> Subject: Re: deleting objects from a pool >> >>> -----Original Message----- >>> From: ceph-devel-owner@vger.kernel.org [mailto:ceph-devel- >>> owner@vger.kernel.org] On Behalf Of Deneau, Tom >>> Sent: Wednesday, June 24, 2015 6:44 PM >>> >>> I have benchmarking situations where I want to leave a pool around >>> but delete a lot of objects from the pool. Is there any really fas= t >>> way to do >> that? >>> I noticed rados rmpool is fast but I don't want to remove the pool. >>> >>> I have been spawning multiple threads, each deleting a subset of th= e >> objects >>> (which I believe is what rados bench write does) but even that can >>> be very slow. >> For now, apart from "rados -p cleanup" (which doesn't pur= ge >> the pool, but merely removes objects written during last benchmark >> run), the only option is by brute force: >> >> for i in $(rados -p ls); do (rados -p rm $i >> &>/dev/null &); done; >> >> There's no "purge pool" command in rados -- not yet, at least. I was >> thinking about one, but never really had time to implement one. >> >> With best regards / Pozdrawiam >> Piotr Da=B3ek >> -- >> To unsubscribe from this list: send the line "unsubscribe ceph-devel= " >> in the body of a message to majordomo@vger.kernel.org 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@vger.kernel.org More majordomo i= nfo 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@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" i= n the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html