Chris Murphy posted on Thu, 11 Sep 2014 15:25:51 -0600 as excerpted: > On Sep 11, 2014, at 1:31 PM, Duncan <1i5t5.dun...@cox.net> wrote: >> >> I wouldn't try defragging now, but it might be worthwhile to stop the >> device delete (rebooting to do so since I don't think there's a cancel) > > 'btrfs replace cancel' does exist, although I haven't tried it.
Btrfs replace cancel exists, yes, but does it work for btrfs device delete, which is what the OP used? > Something isn't right though, because it's clearly neither reading nor > writing at anywhere close to 1/2 the drive read throughput. I'm curious > what 'iotop -d30 -o' shows (during the replace, before cancel), which > should be pretty consistent by averaging 30 seconds worth of io. And > then try 'iotop -d3 -o' and see if there are spikes. I'm willing to bet > there's a lot of nothing going on, with occasional spikes, rather than a > constant trickle. > > And then the question is to find out what btrfs is thinking about while > nothing is reading or writing. Even though it's not 5000+ snapshots, I > wonder if the balance code (and hence btrfs replace) makes extensive use > of fiemap that's causing this to go catatonic. > http://comments.gmane.org/gmane.comp.file-systems.btrfs/35724 Not sure (some of that stuff's beyond me), but one thing we /do/ know is that btrfs has so far been focused mostly on features and debugging, not on optimization beyond the worst-cases, which themselves remain a big enough problem, tho it's slowly getting better. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
