I wrote a simple benchmark that illustrates my issue with deleting files taking a painfully long time.
- Code: Select all
#!/bin/bash
mkdir rmbench >/dev/null 2>&1
cd rmbench || exit
echo -n Creating files...
for f in {1..100}; do dd if=/dev/zero of=rmbenchfile.${f} bs=512 count=1 >/dev/null 2>&1; done
echo; echo Removing files...
sync
time rm rmbenchfile.*
exit
All the disks I'm testing on are in the same set of 4-bay OWC thunderbolt 2 enclosures chained off the Mac mini (specs in original post).
I ran the test three times and took the average.
I created an APFS and HFS partition on a single disk, a single disk ZFS pool, and the rest is a 6-disk RAIDZ2 pool.
APFS: 0m0.012s
HFS: 0m0.11s
ZFS single disk pool (zfstest): 0m1.056s
ZFS RAIDZ2 pool (spool): 0m25.268s
I'll accept that the zfstest pool (single disk) took roughly 9x a long to delete the same files as APFS/HFS, but the RAIDZ2 pool took ~25x as long as the zfstest pool and that I'm trying to explain.
- Code: Select all
zfstest sync standard default
spool sync standard default
I have also tested using the unlink() system call from Perl; it's just as slow as rm(1).
I created a variant of this test that renames the 100 files to something else in the same filesystem and that took about .25 seconds on average to rename all 100, so really wondering what's going on with rm/unlink.