Re: [linux-lvm] Snapshot behavior on classic LVM vs ThinLVM

[Gionatan Danti <g.danti@assyoma.it>]

On 15/05/2017 14:50, Zdenek Kabelac wrote> Hi
> 
> I still think you are mixing apples & oranges together and you expecting 
> answer '42' :)

'42' would be the optimal answer :p

> There is simply NO simple answer. Every case has its pros & cons.
> 
> There is simply cases where XFS beats Ext4 and there are opposite 
> situations as well.

Maybe I'm too naive, but I have an hard time grasping all the 
implication of this sentence.

I fully understand that, currently, a full thinp is basically a "damaged 
disk", where some writes can complete (good/provisioned zones) and some 
fail (bad/unprovisioned zones). I also read the device-mapper docs and I 
understand that, currently, a "fail all writes but let reads succeed" 
target does not exists.

What I does not understand is how XFS and EXT4 differs when a thinp is 
full. From a previous your reply, after I asked how to put thinp in read 
only mode when full:

"Using 'ext4' with remount-ro is fairly easy to setup and get exactly 
this logic."

My naive interpretation is that when EXT4 detects *any* I/O error, it 
will set the filesystem in read-only mode. Except that my tests show 
that only failed *metadata* update put the filesystem in this state. The 
bad thingh is that, when not using "remount-ro", even failed metadata 
updates will *not* trigger any read-only response.

In short, I am right saying that EXT4 should *always* be used with 
"remount-ro" when stacked on top of a thinp?

On the other hand, XFS has not such options but it, by default, ensures 
that failed *metadata* updates will stop the filesystem. Even reads are 
not allowed (to regain read access, you need to repair the filesystem or 
mount it with "ro,norecovery").

So, it should be even safer than EXT4, right? Or do you feel that is the 
other way around? If so, why?

> Things are getting better -  but  planning  usage of thin-pool to 
> 'recover' overfilled pool is simple BAD planning. You should plan your 
> thin-pool usage to NOT run out-of-space.

Sure, and I am *not* planning for it. But as bad things always happen, 
I'm preparing for them ;)

> And last comment I always say -  full thin-pool it not  similar to full 
> filesystem where you drop some 'large' file and you are happily working 
> again - it's not working this way - and if someone hoped into this - he 
> needs to use something else ATM.

Absolutely.

Sorry if I seem pedantic, I am genuinely try to understand.
Regards.

-- 
Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it
email: g.danti@assyoma.it - info@assyoma.it
GPG public key ID: FF5F32A8