Hi, > On Mar 27, 2017, at 3:46 PM, Austin S. Hemmelgarn <ahferro...@gmail.com> > wrote: >> >>> Something I’d like to verify: does having traffic on the volume have >>> the potential to delay this infinitely? I.e. does the system write >>> to any segments that we’re trying to free so it may have to work on >>> the same chunk over and over again? If not, then this means it’s >>> just slow and we’re looking forward to about 2 months worth of time >>> shrinking this volume. (And then again on the next bigger server >>> probably about 3-4 months). >> >> I don't know. I would hope not, but I simply don't know enough >> about the internal algorithms for that. Maybe someone else can confirm? > I'm not 100% certain, but I believe that while it can delay things, it can't > do so infinitely. AFAICT from looking at the code (disclaimer: I am not a C > programmer by profession), it looks like writes to chunks that are being > compacted or moved will go to the new location, not the old one, but writes > to chunks which aren't being touched by the resize currently will just go to > where the chunk is currently. Based on this, lowering the amount of traffic > to the FS could probably speed things up a bit, but it likely won't help much.
I hoped that this is the strategy implemented, otherwise it would end up in an infinite cat-and-mouse game. ;) >>> (Background info: we’re migrating large volumes from btrfs to xfs >>> and can only do this step by step: copying some data, shrinking the >>> btrfs volume, extending the xfs volume, rinse repeat. If someone >>> should have any suggestions to speed this up and not having to think >>> in terms of _months_ then I’m all ears.) >> >> All I can suggest is to move some unused data off the volume and do >> it in fewer larger steps. Sorry. > Same. > > The other option though is to just schedule a maintenance window, nuke the > old FS, and restore from a backup. If you can afford to take the system > off-line temporarily, this will almost certainly go faster (assuming you have > a reasonably fast means of restoring backups). Well. This is the backup. ;) Thanks, Christian -- Christian Theune · c...@flyingcircus.io · +49 345 219401 0 Flying Circus Internet Operations GmbH · http://flyingcircus.io Forsterstraße 29 · 06112 Halle (Saale) · Deutschland HR Stendal HRB 21169 · Geschäftsführer: Christian. Theune, Christian. Zagrodnick
signature.asc
Description: Message signed with OpenPGP
