On Oct 27, 2018, at 12:40 PM, Thomas Fjellstrom <thomas@xxxxxxxxxxxxx> wrote: > > Hi > > As of the past few months or so I've been dealing with my workstation locking > up for upwards of minutes at a time when deleting a large directory tree. I > don't recall this being a problem before. > > Current setup is 3 SATA SSDs in an lvm vg. most space is allocated to an ext4 > /home where my work projects live. > > The main use case causing problems is deleting the "out" directory of an > android AOSP build tree. It can be upwards of 95GB in size with 240k or more > files. If I run a `rm -fr out` or `make clean` it will lock up anything > attempting to use the disk (eg: plasma, intellij, android studio, chrome, etc) > for sometimes minutes. > > I have tried different block scheduler settings including none, mq-deadline, > kyber and bfq none of which seem to improve things much at all. > > It may be worth noting that disk space is starting to run low, perhaps there's > some interaction going on with free space handling or ssd wear leveling... > > That said, it seems to have started happening (or at least made worse) some > time around when mq was made the default and only implementation for sata. > > if it helps, my system specs are: > > Kernel: Debian Sid's 4.18.0-2-amd64 (4.18.10-2) > CPU: AMD FX-8320 OCed to 4.4Ghz > RAM: 32GB DDR3 1866 > MB: Asus 970 Aura Pro Gaming > Storage: Kingston HyperX 3K 240G + Samsung 850 Evo 250G + SanDisk X300 500G > > I'm thinking of testing with a different or older kernel, what would be the > best to test with? Can you try 4.19? A patch went in since 4.18 that fixes a starvation issue around requeue conditions, which SATA is the one to most often hit. Jens
