XCP delete - show a list of all deleted files

[MichalZborovsky]

Hi
Im trying to use xcp for deleting a huge amount of old files on a volume with 127963385 used indoes.
xcp seems a good option for this task as the speed of deletion is high, but I need to get a list of all files the have been deleted.
For reference: scan -l  - is listing files that matched the criteria, I want the same for the delete.
Tried to increase -loglevel to DEBUG but it doesnt give me the output I need. 
Is there any workaround / solution for this ? 
Scanning it first and then deleting will take too long ...

* Another thing that missing in the delete command is defining the threads as copy/verify/sync command have (-parallel) - what is the default for the delete command ?

Thanks

[elementx]

It's been a while since I used XCP for that, but when I did [1] I logged its actions and kept the log.

The use case for this was that the operator had to produce a cryptographically verifiable report of their actions. In the video that's towards the very end when the log is signed by PGP.

Don't know about defining the threads. I'd observe the number of deletes per second and use multiple XCP nodes if one is not enough.

[1]
https://www.youtube.com/watch?v=aoXAH60RLI4

[EWILTS_SAS]

We delete many, many millions of files per day.  We have 5 dedicated VMs that run XCP, each processing a subset of our volumes.  
I've asked about running multiple xcp deletes on a single system and was told that this is not supported (just like xcp copy).  Unless xcp copy, the delete jobs don't need a large footprint - 4 CPUs and 16GB in a VM works well for us.

[elementx · Accepted solution]

Yes, I agree that deletes are light.

> I've asked about running multiple xcp deletes on a single system and was told that this is not supported (just like xcp copy). 

In my personal opinion, you don't get "support" for XCP as such. So if found that useful (maybe for security or other reasons) I'd run multiple instances per VM if I needed to...  And if I found a bug that way, I'd re-run the job to duplicate it in a VM and let NetApp know. One way to do it is containers.

One challenge with NFS Src/Dst might be accessing NFS from containers, but that should be solvable.

I haven't had requests for XCP, but recently I had a query for a more convenient approach to deploying and scaling Cloud Sync and I got it working nicely in containers for S3-to-S3 replication. Unlike XCP, Cloud Sync is a paid service, running in containers is not supported and people can contact Support for problems and expect production-level Support SLAs, so I won't share that link here, but I blogged about containerized CloudSync early this week - it's not a detailed recipe, but some high level thoughts.