On 2017-03-27 09:50, Christian Theune wrote:
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. ;)
I know that balance and replace work this way, and the code for resize
appears to handle things similarly to both, so I'm pretty certain it
works this way. TBH though, it's really the only sane way to handle
something like this.
(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. ;)
Ah, yeah, that does complicate things a bit more.
--
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
