[Top] [All Lists]

Re: any chance for xfs shrinking?

To: Andrey Korolyov <andrey@xxxxxxx>,Stefan Priebe - Profihost AG <s.priebe@xxxxxxxxxxxx>
Subject: Re: any chance for xfs shrinking?
From: greg.freemyer@xxxxxxxxx
Date: Tue, 12 May 2015 21:27:09 -0400
Cc: Eric Sandeen <sandeen@xxxxxxxxxxx>,"xfs@xxxxxxxxxxx" <xfs@xxxxxxxxxxx>
Delivered-to: xfs@xxxxxxxxxxx
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:in-reply-to:references:mime-version :content-transfer-encoding:content-type:subject:from:date:to:cc :message-id; bh=ISudrISbOgySYYF06y+fkcJu8Cp+sEKNqOEi9kJf/qU=; b=VCvmG24dd2gv8+oqcYTRXAZ5uSzRyC5HEyj/o0eWVhDBVf8LMc9afBBxea7diH2R8G RUllKxbH6NaA7ofoOrj0otPd0ky5k2p6SKZ/f5OtIM/BSYN2ygp7lsc2Y4AssFK6UWS/ H6V0JoU/Ss65U18z+cwOUJ1d3+DgUNrIOk9LEzjxAL7uVXS/2mJhuy7e/xG2utcLVwZ4 fYwyTz3WjZzigfVS8aaz/83Tfljaym9bdKQtCVuOPSUk1WE5MfnDa37Gi5nxYBhcotqx YQjg0JQ12qPOE5JYX0SfV5InUJ+gfDm3Wjppn50gFJmCYRKKOl/owjhO/BNuRpjrrMqh 7NVA==
In-reply-to: <CABYiri-9HN3UEThEHJ6_cboyvWgjz1h+E7qaX8kbADh+idQOiQ@xxxxxxxxxxxxxx>
References: <5551EBB2.9010508@xxxxxxxxxxxx> <5551F38A.2050102@xxxxxxxxxxx> <5551F508.2000508@xxxxxxxxxxxx> <CABYiri-9HN3UEThEHJ6_cboyvWgjz1h+E7qaX8kbADh+idQOiQ@xxxxxxxxxxxxxx>
User-agent: K-9 Mail for Android

On May 12, 2015 2:22:16 PM EDT, Andrey Korolyov <andrey@xxxxxxx> wrote:
>On Tue, May 12, 2015 at 3:41 PM, Stefan Priebe - Profihost AG
><s.priebe@xxxxxxxxxxxx> wrote:
>> Am 12.05.2015 um 14:35 schrieb Eric Sandeen:
>>> On 5/12/15 7:01 AM, Stefan Priebe - Profihost AG wrote:
>>>> Hi,
>>>> while cloud / vms usage become more and more popular and qemu now
>>>> offers memory hot add and unplug, cpu hot add and unplug, we still
>>>> suffer from a missing xfs shrink.
>>> Filesystem shrink is a very different scenario than "cloud / vms"
>>> for hot memory & cpu plugging, IMHO.
>>>> I would like to continue to use XFS as it is a rock solid base
>>>> around 10 years for us.
>>>> But one missing piece in variable ressource usage for us is disk
>>>> shrinking. Is there any chance to get an xfs online shrinking?
>>> Under what circumstance does your workflow require a filesystem
>> May be special but there are a lot of customers out there who do not
>> manager their ressources. So they've partners and partners of
>> It happens quite often that the disk runs out of space and the
>> does not know what he can do as third parties control the waste of
>> space. So we are in the situation where we need to extent the
>> so the customer can continue his business. Later when the partner has
>> solved the issue (real world shows mostly 2 days - 3 weeks) the
>> wants to shrink again as he does not want to pay the space.
>>> Honest question, I'm not challenging you, but I would like to
>>> what it is about shrink that is so critical it may cause you to stop
>>> XFS.
>>> One thing about shrink - while i.e. ext4 supports it, the end result
>>> a shrunk filesystem is a scrambled filesystem.  All those heuristics
>>> made the filesystem reasonably performant as it aged get thrown out
>>> window as the fs scavenges for space into which to shrink the
>>> That said, another option is to use the dm-thinp target, and
>allocate /
>>> de-allocate storage resources to the underlying block device as
>> We do so while using ceph and trim but the customer pays what he can
>> theoretically use and not what he uses in real. Ceph also does not
>> provide a way to show us the real usage of a rbd disk.
>> Greets,
>> Stefan
>Am I right in a guess that this indirect management issue is a primary
>reason for having online shrinking as a feature? You can use BTRFS at
>it is supporting in-place shrink and achieved enough stability with
>plain use-cases, with enough necessity. Of course having simular thing
>in an XFS would be quite awesome for a general purpose or for a
>visionary case, but the real-world need in such a feature is a bit
>limited, from at least cloud provider` point of view.
>xfs mailing list

Sent from my Android device with K-9 Mail. Please excuse my brevity.

<Prev in Thread] Current Thread [Next in Thread>