XFS shrinking planned?

XFS shrinking planned?

[Spelic]

Hello all,
XFS is such a good high performance filesystem, kudos for that.

However for large filesystems (which are mainly those that require high 
performance) the ability to shrink would be really needed. People 
usually do not have double the space so to move files to a smaller XFS 
filesystem, and the inability of XFS to shrink forbids major 
reorganizations of the storage systems.

Currently, for that reason I use ext4. Performance is still decent and 
flexibility is higher due to the ability to shrink, but I would use XFS 
if it could shrink.

I suppose shrinking ability is not even planned, is it?

Thank you
S.

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: XFS shrinking planned?

[Eric Sandeen]

On 10/28/14 11:19 AM, Spelic wrote:
> Hello all,
> XFS is such a good high performance filesystem, kudos for that.
> 
> However for large filesystems (which are mainly those that require high performance) the ability to shrink would be really needed. People usually do not have double the space so to move files to a smaller XFS filesystem, and the inability of XFS to shrink forbids major reorganizations of the storage systems.
> 
> Currently, for that reason I use ext4. Performance is still decent and flexibility is higher due to the ability to shrink, but I would use XFS if it could shrink.
> 
> I suppose shrinking ability is not even planned, is it?

Not formally planned, there are bits and pieces out there (i.e. the inode
mover) which are part of what it might take to achieve a shrinker.

Another option, rather than fs shrinking, is to use the dm-thinp target, which
would allow you to allocate a large-but-sparse block device, create a very
large filesystem on that, and add or remove storage as needed.
(At least I think you can remove it...!)

-Eric

> Thank you
> S.

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: XFS shrinking planned?

[Spelic]

On 28/10/2014 18:39, Eric Sandeen wrote:
> Not formally planned, there are bits and pieces out there (i.e. the inode
> mover) which are part of what it might take to achieve a shrinker.
>
> Another option, rather than fs shrinking, is to use the dm-thinp target, which
> would allow you to allocate a large-but-sparse block device, create a very
> large filesystem on that, and add or remove storage as needed.
> (At least I think you can remove it...!)
>
> -Eric

Thanks for your reply Eric

Interesting technique, but for enforcing a maximum size (smaller than 
the very large allocated thin device) I would have to rely on quotas, 
which probably decreases performance.
Then using thinp would mess up all the disk layout, basically replacing 
the XFS allocator, which most likely would decrease performances 
significantly.
And then the thinp code itself is a medium performance thing and I don't 
think it can keep up with XFS performances, so that would presumably be 
a hard bottleneck.
All this would result in a performance almost certainly lower than ext4.

Thanks
S.

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: XFS shrinking planned?

[Eric Sandeen]

On 10/29/14 4:37 AM, Spelic wrote:
> On 28/10/2014 18:39, Eric Sandeen wrote:
>> Not formally planned, there are bits and pieces out there (i.e. the inode
>> mover) which are part of what it might take to achieve a shrinker.
>>
>> Another option, rather than fs shrinking, is to use the dm-thinp target, which
>> would allow you to allocate a large-but-sparse block device, create a very
>> large filesystem on that, and add or remove storage as needed.
>> (At least I think you can remove it...!)
>>
>> -Eric
> 
> Thanks for your reply Eric
> 
> Interesting technique, but for enforcing a maximum size (smaller than
> the very large allocated thin device) I would have to rely on quotas,
> which probably decreases performance.

"probably"

> Then using thinp would mess up
> all the disk layout, basically replacing the XFS allocator, which
> most likely would decrease performances significantly.

"most likely"

> And then the
> thinp code itself is a medium performance thing and I don't think it
> can keep up with XFS performances, so that would presumably be a hard
> bottleneck.

"presumably"

> All this would result in a performance almost certainly
> lower than ext4.

"almost certainly..."
 
All possibilities, but possibly also worth testing to find out.  ;)
It's true that today the thinp allocator will impact XFS allocation
patterns to some degree.

Anyway, shrink has been on the radar for years, it's just never really
been a priority.  It might happen some day...

-Eric

> Thanks
> S.
> 

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs