[linux-lvm] Reserve space for specific thin logical volumes

Zdenek Kabelac zkabelac at redhat.com
Tue Sep 12 23:11:39 UTC 2017


Dne 13.9.2017 v 00:55 Gionatan Danti napsal(a):
> Il 13-09-2017 00:41 Zdenek Kabelac ha scritto:
>> There are maybe few worthy comments - XFS is great on stanadar big
>> volumes, but there used to be some hidden details when used on thinly
>> provisioned volumes on older RHEL (7.0, 7.1)
>>
>> So now it depend how old distro you use (I'd probably highly recommend
>> upgrade to RH7.4 if you are on RHEL based distro)
> 
> Sure.
> 
>> Basically 'XFS' does not have similar 'remount-ro' on error behavior
>> which 'extX' provides - but now XFS knows how to shutdown itself when
>> meta/data updates starts to fail - although you may need to tune some
>> 'sysfs' params to get 'ideal' behavior.
> 
> True, with a catch: with the default data=ordered option, even ext4 does *not* 
> remount read only when data writeout fails. You need to use both 
> "errors=remount-ro" and "data=journal" which basically nobody uses.
> 
>> Personally for smaller sized thin volumes I'd prefer 'ext4' over XFS -
>> unless you demand some specific XFS feature...
> 
> Thanks for the input. So, do you run your ext4 filesystem with data=journal? 
> How they behave performane-wise?
> 

As said     data=journal   is big performance killer (especially on SSD)

Personally  I prefer early 'shutdown' in case the situation becomes critical
(i.e. 95% fullness because some process gets crazy)

But you can write any advanced scripting logic to suit best your needs -

i.e. replace all thins on thin-pool with 'error' target....
(which  is as simple as using  'dmsetup remove --force'.... - this will
make all future read/writes  giving you  i/o errors....)

Simply do all in user-space early enough before  thin-pool can ever get NEAR t 
being 100% full -  reaction is really quick - and you have at least 60seconds 
to solve the problem in worst case.....



Regards

Zdenek




More information about the linux-lvm mailing list