3 ms·
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 beyon
by bubblethink 9y ago
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.
- lima 9y agoYes 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.
- bubblethink 9y agoNo, 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.
- lima 9y agoLVM snapshots are really slow though.
- bubblethink 9y agoThat's the whole selling point of thinp (at least for root and home). They are supposed to be faster than regular snapshots.