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
_______________________________________________
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
