Bug #58282 | "mtr --mem" does not work on a machine with libaio installed | ||
---|---|---|---|
Submitted: | 18 Nov 2010 10:38 | Modified: | 20 Dec 2010 3:08 |
Reporter: | Alexander Barkov | Email Updates: | |
Status: | Closed | Impact on me: | |
Category: | Tools: MTR / mysql-test-run | Severity: | S3 (Non-critical) |
Version: | mysql-5.5-bugteam | OS: | Linux (Fedora) |
Assigned to: | Bjørn Munch | CPU Architecture: | Any |
Tags: | regression |
[18 Nov 2010 10:38]
Alexander Barkov
[18 Nov 2010 18:12]
Sveta Smirnova
Thank you for the report. Verified as described. Version 5.1 is not affected.
[18 Nov 2010 18:28]
Calvin Sun
Using --mem, you should turn native aio off: innodb_use_native_aio. It is on by default.
[18 Nov 2010 18:32]
Davi Arnaut
Perhaps MTR should do that? I guess it's a bit hard to deduce from a failed boostrap (with a invalid error message in the error log) that one can't run --mem with libaio installed.
[18 Nov 2010 18:44]
Calvin Sun
Yes, it is better to be fixed in mtr. It is problematic for storage engine to detect which kind of file system is used.
[18 Nov 2010 20:11]
Sveta Smirnova
It really fails with same error for test without --mem as well.
[18 Nov 2010 20:18]
Sveta Smirnova
For my test for bug #58060 innodb_use_native_aio did not help.
[19 Nov 2010 9:07]
Bjørn Munch
It's not straightforward for mtr either to know if you're running on a memory file system. If you run mtr --mem it will create a softlink var to your vardir and if you run mtr again without --mem and it finds a var softlink, it will use that, whatever it points to. You may also override with --vardir=<path>. You may of course also have your entire workspace in a memory file system.
[19 Nov 2010 9:10]
Davi Arnaut
Indeed, but special cases aside, at least for --mem it should be worth the effort to supply the command line to InnoDB.
[23 Nov 2010 19:34]
Sveta Smirnova
Bug #58421 was marked as duplicate of this one.
[1 Dec 2010 12:12]
Bjørn Munch
I can reproduce the problem all right, but adding --skip-innodb-use-native-aio to the mysqld bootstrap command seems to have no effect? I get the exact same error: --- InnoDB: Error: auto-extending data file ./ibdata1 is of a different size InnoDB: 0 pages (rounded down to MB) than specified in the .cnf file: InnoDB: initial 640 pages, max 0 (relevant if non-zero) pages! InnoDB: Could not open or create data files.
[3 Dec 2010 9:49]
Bjørn Munch
I reopened Bug #58421 as not a duplicate of this. That is the core problem, this is a (partial) mtr workaround.
[8 Dec 2010 13:56]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/126323 3123 Bjorn Munch 2010-12-08 Bug #58282 "mtr --mem" does not work on a machine with libaio installed Workaround: add --loose-skip-innodb-use-native-aio Only on linux if explicitly using --mem or setting $OPT_MEM
[9 Dec 2010 12:43]
Jonathan Perkin
Fine, as long as it gets removed once the original bug is fixed :-)
[9 Dec 2010 13:05]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/126416 3126 Bjorn Munch 2010-12-09 Bug #58282 "mtr --mem" does not work on a machine with libaio installed Workaround: add --loose-skip-innodb-use-native-aio Only on linux if explicitly using --mem or setting $OPT_MEM
[9 Dec 2010 16:21]
Bjørn Munch
Pushed to 5.5-mtr, trunk-mtr
[17 Dec 2010 12:53]
Bugs System
Pushed into mysql-5.5 5.5.9 (revid:georgi.kodinov@oracle.com-20101217124733-p1ivu6higouawv8l) (version source revid:bjorn.munch@oracle.com-20101209195322-embe21sfutgb3oy0) (merge vers: 5.5.8) (pib:24)
[17 Dec 2010 12:57]
Bugs System
Pushed into mysql-trunk 5.6.1 (revid:georgi.kodinov@oracle.com-20101217125013-y8pb3az32rtbplc9) (version source revid:anitha.gopi@sun.com-20101210041312-50t9adyhwwybsm6x) (merge vers: 5.6.1) (pib:24)
[20 Dec 2010 3:08]
Paul DuBois
Changes to test suite. No changelog entry needed.