On Wed, Jun 10, 2020 at 09:56:11PM -0400, Ellis H. Wilson III wrote: > On 6/9/20 7:09 PM, Hans van Kranenburg wrote: > > * (not recommended) If your mount options do not show 'ssd' in them and > > your kernel does not have this patch: > > https://www.spinics.net/lists/linux-btrfs/msg64203.html then you can try > > the mount -o ssd_spread,nossd (read the story in the link above). > > Anyway, you're better off moving to something recent instead of trying > > all these obsolete workarounds... > > I forgot to respond to this in my last email. The version of BTRFS running > in my openSuSE 15.0 kernel does indeed have that patch. > > Nevertheless, I tried with just ssd_spread for kicks, and it showed no major > improvement, and had the same growth pathology as past runs had: > > 0f70583cd12cac:/pandata/0 # time (for i in {1..10}; do time (rm test$i; > sync); done) > real 0m0.636s > real 0m0.649s > real 0m0.417s > real 0m0.562s > real 0m0.381s > real 0m0.949s > real 0m2.014s > real 0m2.129s > real 0m2.074s > real 0m5.114s > > Total: > real 0m14.939s > > Even more curiously, when I repeat this experiment using ext4 (lazy init was > disabled) on the exact same disks, I see a nearly identical slowdown > pathology: > > real 0m0.122s > real 0m0.048s > real 0m0.075s > real 0m0.076s > real 0m0.100s > real 0m0.499s > real 0m1.658s > real 0m1.709s > real 0m1.716s > real 0m6.599s > > Total: > real 0m12.614s > > Very wonky. Maybe this has something to do with the mdraid we use > underneath both, or maybe it's something architectural I'm not immediately > grasping that impacts all extent-based filesystems. Will report back when I > have blktraces. Not just extent-based. ext2 and ext3 had O(n) deletes too, and they used block lists. > Best, > > ellis
