It's probably a single thread process to do the deletions.
If possible, from a client, start multiple deletions deep in the tree.
I have had to do this trick with deletions and with rsync in the past
Forever the multithreaded-nessÂ
Sent from Mobile Outlook
On Sat, Sep 26, 2015 at 9:16 AM -0700, "Patrick Giagnocavo" <firstname.lastname@example.org> wrote:
I wonder if (like in Unix), as the number of files left drops, the rate of deletion will increase or go faster.Â I found in one case that the time was being taken in reading then re-writing the filesystem directory index of files.Â As the number dropped from 100,000+ files the rate of deletes increased.
On Fri, Sep 25, 2015 at 7:19 AM, <email@example.com> wrote:
Pretty sure the only shortcutâ€Ž is volume operations like qtree snapmirror.Â
SentÂ fromÂ myÂ BlackBerryÂ 10Â smartphoneÂ onÂ theÂ BellÂ network. From: Edward RolisonSent: Friday, September 25, 2015 8:48 AMTo: Basil BCc: firstname.lastname@example.orgSubject: Re: File delete rate
Bonus question would be - does that also apply if you do it via a "qtree delete -f" or is the API delete run at about the same speed?Â
On 25 September 2015 at 13:31, <email@example.com> wrote:
Yes, that seems possible. Operations working on large numbers of small files always take a long time.
SentÂ fromÂ myÂ BlackBerryÂ 10Â smartphoneÂ onÂ theÂ BellÂ network. From: Edward RolisonSent: Friday, September 25, 2015 8:00 AMTo: firstname.lastname@example.orgSubject: File delete rate
Apologies if this seems a bit vague - I'm in need of a quick sanity check.Â
Doing a qtree delete - it's taking 'a while'.Â
This seems to be because it's deleting every file at a rate of 50-100 files per second, and there's about a million files in the qtree.
Is that a 'reasonable' rate of deletion? (This is using an API based 'file-delete-file' operation, if that's relevant).Â
Toasters mailing list