Yeah, I used to do the way you wrote before, but in fact, G means
gigabyte (1024^3), and works the same with both tools. On smaller units
You have to watch for the rounding to extent size (4M by default).
Moreover, some could use:
btrfs fi re -2G /mount (well, I just noticed, I accidentally
wrote the device last time, but btrfs resize should be used on mount point.)
lvresize -L -2G /device
:)
DBLaci
And of course, this is what should be done to prevent data loss. This
method won't fix the original problem of course...
Thanks for your comment!
2014-01-11 20:16 keltezéssel, Roman Mamedov írta:
On Sat, 11 Jan 2014 19:48:55 +0100
Szalma László <dbl...@dblaci.hu> wrote:
2014-01-11 18:10 keltezéssel, MegaBrutal írta:
How can I shrink the FS to the correct size right now, ensuring that I
really shrink it to the exact LV size?
btrfs fi re 10G /dev/mapper/vg-lv
lvresize -L 10G vg/lv
That's setting yourself up for a failure if these tools happen to disagree on
what "G" means (GB vs GiB). Maybe that's what happened here with the thread
starter's FS?
To be completely safe, I would recommend to resize the FS in two steps, leaving
some safety margin to the partition resize first:
btrfs fi re 8G /dev/mapper/vg-lv
lvresize -L 10G vg/lv
btrfs fi re max /dev/mapper/vg-lv
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
