Re:Red Hat Enterprise Linux 7.4 Released
by bubblethink on Tuesday August 01, 2017 @04:52PM
(#14905191)
The default metadata pool size chosen by anaconda, at least up to RHEL 7.3, is paltry. Something like 100 MB for terabytes of data. Why they chose that is beyond me. Anaconda won't let you configure it manually during installation either. It'll get full in no time. Automatic extension is disabled by default. If you're lucky, you'll realize this by looking at your own logs. Then you'll try to extend it, at which point you'll realize that extending it won't extend the pmspare vol, and you've effectively disabled the pmspare functionality.
[ Parent
| on HN ]
Yes but that's well-known and documented. Including it in Anaconda looks like an oversight though (a thinp deployment needs to be well-planned and you'd definitely want to read the docs).
There's a whole book-sized section about in the storage docs.
The docker-storage-setup utility, for example, sets it up correctly and enables automatic extension.
Re:Red Hat Enterprise Linux 7.4 Released
by bubblethink on Tuesday August 01, 2017 @05:04PM
(#14905305)
No, the use in Anaconda is perfectly legitimate. Docker aside, I use it for automatic snapshots. That's a fairly useful and unique feature that you can't have in any other legit way (not counting zfs, and btrfs is deprecated). There is also the yum-snapshot plugin that relies on it. It's not even that complicated. Just throw a few gigs at metadata and forget about extensions. If I have 2TB hard drives, I don't care if you use 16 G for metadata, which is the max.
LVM snapshots are really slow though.
Re:Red Hat Enterprise Linux 7.4 Released
by bubblethink on Tuesday August 01, 2017 @05:15PM
(#14905421)
That's the whole selling point of thinp (at least for root and home). They are supposed to be faster than regular snapshots.