https://bugzilla.kernel.org/show_bug.cgi?id=200371 --- Comment #3 from mcolgin@xxxxxxxxx --- @theodore RE: So I'm really interested in how the file system got to that state. If you have the history of how the file system was resized up until now, that would be really useful. I went through my "~/.bash_history" to pull out the commands used that lead to the error. The commands listed under "HISTORY" were performed throughout 2017 and the LV was grown incrementally over time with relative sizing. HISTORY ======= lvextend --size +200G /dev/vg_areca/lv_mylvname resize2fs -f /dev/vg_areca/lv_mylvname lvextend --size +100G /dev/vg_areca/lv_mylvname resize2fs /dev/vg_areca/lv_mylvname lvextend --size +100G /dev/vg_areca/lv_mylvname resize2fs -f /dev/vg_areca/lv_mylvname lvextend --size +500G /dev/vg_areca/lv_mylvname lvextend --size +500G /dev/vg_areca/lv_mylvname resize2fs -f /dev/vg_areca/lv_mylvname These "HISTORY" commands are many months old, the command which led to the error is here.. in which this LV was locked down to a specific size, as no other files were going to be added to it.. NOTE: the "tune2fs" which reduced free blocks, my retrieving of "--getbsz" to get an absolutely blocks needed for the subsequent "lvreduce --size 8766G" OP THAT LEAD TO ERROR ===================== e2fsck -f /dev/vg_areca/lv_mylvname tune2fs -m 0.0 /dev/vg_areca/lv_mylvname blockdev --getbsz /dev/vg_areca/lv_mylvname resize2fs /dev/vg_areca/lv_mylvname 8766G lvreduce --size 8766G /dev/vg_areca/lv_mylvname mount /dev/vg_areca/lv_mylvname -- You are receiving this mail because: You are watching the assignee of the bug.
