search

archiecobbs / s3backer

FUSE/NBD single file backing store via Amazon S3
Other
535 stars 77 forks source link

TRIM is very inefficient #192

Closed Nikratio closed 2 years ago

Nikratio commented 2 years ago

When creating a new ext4 filesystem with a completely empty bucket, the TRIM operation takes forever (I aborted after a few minutes):

# nbdkit --unix /tmp/tmprz2iq_nj/nbd_socket_sb2 --foreground --filter=exitlast --filter=stats --threads 1 --filter=retry s3backer size=50G bucket=nikratio-backup/s3b_sb2 region=eu-west-2 statsfile=/home/nikratio/tmp/buckets/nikratio-backup_sb2_stats.txt statsappend=true s3b_force=true retries=100 retry-readonly=false retry-delay=30 retry-exponential=no blockSize=32K
# nbd-client -unix /tmp/tmprz2iq_nj/nbd_socket_sb2 --timeout 604800 /dev/nbd0
# mkfs.ext4 /dev/nbd0
mke2fs 1.46.2 (28-Feb-2021)
Discarding device blocks: 4096/13107200

I'm not sure what's taking so long, but there's considerable network activity that seems wholly unneeded.

Is it possible that s3backer is trying to unconditionally delete every TRIM'ed block? If so, is there a reason that we're not starting with a single LIST request (which we could scope to just the TRIMed blocks) and then delete only the objects that actually exist?

archiecobbs commented 2 years ago

If so, is there a reason that we're not starting with a single LIST request... and then delete only the objects that actually exist?

Yes :) The reason is that for this to work you need to add the --listBlocks flag (or, in your case listBlocks=true).

archiecobbs commented 2 years ago

Closing issue. Feel free to re-open if needed.