Hide Forgot
Description of problem: It is important that / is mounted with discard to ensure that freed space is also getting freed in the thin pool. Otherwise the thin pool will suffer from free space starvation. Version-Release number of selected component (if applicable): 4.* How reproducible: ? Steps to Reproduce: 1. Install Node/RHVH 2. Check if discard mount option is used on / 3. Update 4. Check if discard mount option is used on / Actual results: Expected results: Additional info:
There is a systemd timer that runs fstrim periodically. Configure it to run once a day - more efficient than the above.
I actually wonder if the fstrim service is a higher risk. Because the service is calling fstrim -a which will trim all mounted file-systems which support discard - and the mounted filesystms are pretty unpredictable. By relying on the discard mount option we ensure that only "our" file-systems will be trimmed. Another thing to conside ris that a fstrim timer is probably as unpredictable as a garbage collector: It will kick in at some point an might degrade performance - and the runtime depends on the pilled up data to be freed. We've got a spike behavior. By using the mount option we have a constant - but more predeictive impact, as we don't pile up a mount of data to be freed.
(In reply to Fabian Deutsch from comment #2) > I actually wonder if the fstrim service is a higher risk. > Because the service is calling fstrim -a which will trim all mounted > file-systems which support discard - and the mounted filesystms are pretty > unpredictable. It is predictable and safe. People have been doing it (unknowingly) for several Fedora releases. > > By relying on the discard mount option we ensure that only "our" > file-systems will be trimmed. > > Another thing to conside ris that a fstrim timer is probably as > unpredictable as a garbage collector: It will kick in at some point an might > degrade performance - and the runtime depends on the pilled up data to be > freed. We've got a spike behavior. It has no performance impact these days. It used to, in the distant past. > > By using the mount option we have a constant - but more predeictive impact, > as we don't pile up a mount of data to be freed. Anyway, moving to 4.0.7. Not critical.
If it is as in comment 3 then it should really not make a difference - and the service solution is easier.
Fabian, discard was already set to / from the mount options since RHVH 4.0 GA.. The block device reclaim space freed. Let's see the final solution by devel.
Closing this according to comment 5. The original bug was probably a manual change.