← Back to team overview

maria-developers team mailing list archive

innodb holepunch compression vs the filesystem

 

InnoDB punch-hole compression is very bad for a filesystem when done on
every (or most) page writes. That feature was not designed to be used in
that manner and generates far too much in-memory metadata in the
filesystem. If nothing else it leads to multi-minute unlink() system calls.
Yet both MariaDB and MySQL proudly exclaim this as a feature.

Are you going to use the same kludge as MySQL (do unlink() in a background
thread) to avoid locking up InnoDB for many minutes during drop table,
maybe leading to InnoDB killing mysqld process?

Why didn't you catch this problem via testing or reading my blog posts?

https://mariadb.com/kb/en/mariadb/compression/
https://blog.mariadb.org/mariadb-10-1-is-stable-ga/

https://bugs.mysql.com/bug.php?id=78277
http://smalldatum.blogspot.com/2015/08/first-day-with-innodb-transparent-page.html
http://smalldatum.blogspot.com/2015/09/second-day-with-innodb-transparent-page.html
http://smalldatum.blogspot.com/2015/09/third-day-with-innodb-transparent-page.html
http://smalldatum.blogspot.com/2015/10/wanted-file-system-on-which-innodb.html

-- 
Mark Callaghan
mdcallag@xxxxxxxxx

Follow ups