On Sep 11, 2014, at 5:51 PM, Duncan <1i5t5.dun...@cox.net> wrote: > 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?
Oops, right! I'm not sure what can do this safely. And then when I think about just creating a new fs, using btrfs send/receive, the snapshots need to be ro first. So if there's any uncertainty about safely canceling the 'device delete' those ro snapshots need to be taken first, in the event only an ro mount is possible subsequently. And then there's some uncertainty how long 260+ ro snapshots will take (should be fast, but) and how much worse that makes the current situation. But probably worth the risk to take the snapshots and just wait a while before trying something like umount or sysrq+s followed by sysrq+u. > >> 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. Sure. But what's the next step? Given 260+ snapshots might mean well more than 350GB of data, depending on how deduplicated the fs is, it still probably would be faster to rsync this to a pile of drives in linear/concat+XFS than wait a month (?) for device delete to finish. Alternatively, script some way to create 260+ ro snapshots to btrfs send/receive to a new btrfs volume; and turn it into a raid1 later. I'm curious if a sysrq+s followed by sysrq+u might leave the filessystem in a state where it could still be rw mountable. But I'm skeptical of anything interrupting the device delete before being fully prepared for the fs to be toast for rw mount. If only ro mount is possible, any chance of creating ro snapshots is out. Chris Murphy-- 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
