If you try to create an LVM snapshot with
lvm lvcreate -s -n snapname -L 100G myvg
and it fails with
Unable to create a snapshot smaller than 2 chunks.
… it’s probably actually trying to tell you “I don’t have 100GB free on this VG, allocate a smaller snapshot”. It’s choosing to phrase it creatively.
You’ll only get this error if you’re within a certain margin of sizes: much too big and it’ll tell you a rather clearer:
Volume group "myvg" has insufficient free space (1000 extents): 2000 required.
so it’s really just a bit of a limitation or cosmetic bug.
It’s not very Google-able though, hence this post. Next time I hit this error I’ll search for it and find my own writing, having completely forgotten that I was involved in a case where the team I was on saw the problem before, figured it out, and I wrote about it. Surely that happens to everyone.
Right?
Anyway, When it comes to creative error messages LVM is far from alone.
PostgreSQL’s way of saying “nothing more to read right now during archive recovery” is to spew:
cp: cannot stat ‘/path/to/00000001000000000000003C’: No such file or directory
or the equivalent for scp, or rsync, or barman get-wal, or wal-e fetch, or whatever you use into the logs.
pg_xlogdump‘s way of saying “There’s no more WAL to read” is:
FATAL: invalid record length at 1D/1B4C2DAB: wanted 24, got 0
Also, Pg likes to spam the logs with
FATAL: the database system is starting up
FATAL: the database system is starting up
FATAL: the database system is starting up
FATAL: the database system is starting up
when in startup, crash recovery or warm standby. Yes, it’s FATAL to the attempted client connection, but it makes the server log look … alarming … when you’re looking at a perfectly normal recovery. Even more confusing when those client connections are from pg_ctl -w start
So I can’t throw too many stones at LVM’s error messages just yet.