Variable deletion speed.

[rogerh]

An idle question possibly related to zfs, or possibly not. Every day I delete one or two directories containing about 1500 files of about 50MB in size (total folder 82GB). A bit pointless doing it manually, but I do have in mind I might occasionally want to keep them. I use "rm -r <path to directory>". The process never seems to use more than 50% CPU, though I suppose it may saturate one core of the two. The filesystem is a 4 x 3TB RAIDZ2 pool, which is less than 50% full. The machine is rarely doing a great deal with a load average of < 0.5 and CPU 95% idle.

My observation is that deletion sometimes takes less than half a second and sometimes up to a minute or two. Anyone any idea what might affect this?

 

[Ericloewe]

Well, fragmentation would certainly contribute to that, with less-fragmented files being handled more quickly.

 

[joeschmuck]

I agree, file fragmentation is part of the issue. CPU resources are most likely never the cause for what you are experiencing as most of the physical time is done by the heads moving around on the hard drives. I also suspect that RAM usage could be a cause because if you are just comparing the time from when you enter the command to delete the files to when you get a prompt back, well that is not very accurate. I would think (and I'm just thinking out loud here) that if you have some free RAM resources that the command operations are cached in the RAM, the command prompt returns, and the drives are still deleting data. Like I said, just a possibility I think but I don't know with any certainty and I'm thinking SLOG type actions if there is enough RAM not in active use.

I'd like to know if what I'm thinking is possible from someone who knows more about this.

 

[rogerh]

I'm surprised if fragmentation is a big issue as the disks have never been up to half full. Interested in the idea of all the commands being stored in RAM, I have no idea if rm waits for confirmation one file is deleted before deleting the next?

 

[joeschmuck]

I just can't see file fragmentation being 100% of the difference given the same number of files and same file sizes which is why I suspect some caching going on.

 

[rogerh]

I just can't see file fragmentation being 100% of the difference given the same number of files and same file sizes which is why I suspect some caching going on.

That's fairly convincing, thanks for the suggestion. For some reason my machine seems quite regularly to use a few hundred MB of swap, for no very obvious reason. The ARC size is down from about 14GB in some 9.3 versions to 11GB in the recent 9.10.1. I do wonder if there is something I can tune to stop it using swap? I have no idea why it does it.

 

[joeschmuck]

Did a quick Google search to turn off the swap space, here is the link. I think I'd try this on a VM first before testing it out on my real machine.

My system hasn't used the SWAP space in forever. I have a similar setup to yours, 16GB RAM. My ARC is 12GB, the same as my swap size, I think that was just coincidence.

 

[rogerh]

Did a quick Google search to turn off the swap space, here is the link. I think I'd try this on a VM first before testing it out on my real machine.

My system hasn't used the SWAP space in forever. I have a similar setup to yours, 16GB RAM. My ARC is 12GB, the same as my swap size, I think that was just coincidence.

If it needs to swap I wouldn't want to deprive it of the chance. That could cause crashes, depending what process can't continue. I just don't know why it needs to swap.

 

[joeschmuck]

I understand, turning off the swap space is a risk. Here is something else to look at, swapinfo(8) but I don't have a swap file with anything in it so I can't really test it out to see if it can produce any useful data as to what is being stored in the swap location.

I'd be curious if you find something out. But for now, time to start making dinner for the family.

 

[rogerh]

I understand, turning off the swap space is a risk. Here is something else to look at, swapinfo(8) but I don't have a swap file with anything in it so I can't really test it out to see if it can produce any useful data as to what is being stored in the swap location.

I'd be curious if you find something out. But for now, time to start making dinner for the family.

OK, perhaps I'll find something tomorrow, it's midnight here. swapinfo doesn't help, I'll have to look up whether there is a way to read BSD swap directly.