xfs
[Top] [All Lists]

Re: any chance for xfs shrinking?

To: Stefan Priebe - Profihost AG <s.priebe@xxxxxxxxxxxx>
Subject: Re: any chance for xfs shrinking?
From: Andrey Korolyov <andrey@xxxxxxx>
Date: Tue, 12 May 2015 21:22:16 +0300
Cc: Eric Sandeen <sandeen@xxxxxxxxxxx>, "xfs@xxxxxxxxxxx" <xfs@xxxxxxxxxxx>
Delivered-to: xfs@xxxxxxxxxxx
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=xdel.ru; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=4lis+VmQlrcinaHQqk307INX9o06pqQtuATpj7NOx7E=; b=oBhmcS9uIRHDq6e0UGvPdbwOCkrci9nbpIMsl3W+ndHbxdOa9eQxLxbJ5gKVyNjsIe wMswWnv/7H+m4mwRNySgcj5sv5wZTsgGqUGMxUxM+wSfE7lpblrWwpSVcS7Jwh1GITdF a1+L58K5KJs0POXBF+50G8kvJLsomP4J4Rczo=
In-reply-to: <5551F508.2000508@xxxxxxxxxxxx>
References: <5551EBB2.9010508@xxxxxxxxxxxx> <5551F38A.2050102@xxxxxxxxxxx> <5551F508.2000508@xxxxxxxxxxxx>
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 also
>>> 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" needs
>> for hot memory & cpu plugging, IMHO.
>>
>>> I would like to continue to use XFS as it is a rock solid base since
>>> 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 shrink?
>
> 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 partners.
> It happens quite often that the disk runs out of space and the customer
> 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 partition
> so the customer can continue his business. Later when the partner has
> solved the issue (real world shows mostly 2 days - 3 weeks) the customer
> 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 understand
>> what it is about shrink that is so critical it may cause you to stop using
>> XFS.
>>
>> One thing about shrink - while i.e. ext4 supports it, the end result of
>> a shrunk filesystem is a scrambled filesystem.  All those heuristics that
>> made the filesystem reasonably performant as it aged get thrown out the
>> window as the fs scavenges for space into which to shrink the filesystem...
>>
>> That said, another option is to use the dm-thinp target, and allocate /
>> de-allocate storage resources to the underlying block device as needed.
>
> 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.

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