InnoDB: Operating system error number 23 in a file operation

nainil used Ask the Experts™
Out of no where I could not initiate the WAMP MySQLd service. Looking in the logs, I found the following:

120103  6:24:07 [Note] Plugin 'FEDERATED' is disabled.
InnoDB: The InnoDB memory heap is disabled
InnoDB: Mutexes and rw_locks use Windows interlocked functions
InnoDB: Compressed tables use zlib 1.2.3
120103  6:24:07  InnoDB: Initializing buffer pool, size = 1.0G
120103  6:24:07  InnoDB: Completed initialization of buffer pool
120103  6:24:07  InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 116924317882
120103  6:24:07  InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
InnoDB: Doing recovery: scanned up to log sequence number 116925735845
InnoDB: Transaction 91F293B was in the XA prepared state.
InnoDB: 2 transaction(s) which must be rolled back or cleaned up
InnoDB: in total 1 row operations to undo
InnoDB: Trx id counter is 91F2B00
120103  6:24:12  InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
InnoDB: Apply batch completed
InnoDB: Last MySQL binlog file position 0 117578624, file name .\mysql-bin.000073
InnoDB: Starting in background the rollback of uncommitted transactions
120103  6:24:24  InnoDB: Rolling back trx with id 91F2939, 1 rows to undo
120103  6:24:24  InnoDB: 1.1.4 started; log sequence number 116925735845
120103  6:24:24 [Note] Recovering after a crash using mysql-bin
120103  6:24:32  InnoDB: Operating system error number 23 in a file operation.
InnoDB: Some operating system error numbers are described at
InnoDB: File name e:\wamp\bin\mysql\mysql5.1.53\data\ibdata1
InnoDB: File operation call: 'Windows aio'.
InnoDB: Cannot continue operation.

What can I do to:
1. Get the WAMP MySQLD service up and running
2. Loose the least amount of data

On a side note, I see alteast several files (approx 1GB each) mysql-bin.000001 to mysql-bin.000073. What are these files? Can I safely purge them?
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
Distinguished Expert 2017

The mysql-bin are the transaction logs
Do you have a full backup of the database?
Using the backup and the mysql-bin for transaction that occurred after the backup, you can restore the database to a point prior to the crash.

check the security settings on e:\wamp\bin\mysql\mysql5.1.53\data\ibdata1
xcacls e:\wamp\bin\mysql\mysql5.1.53\data\ibdata1

You can try and check the files offline


@arnold: How / where can I find the innochecksum utility?

How can I use the backup and mysql-bin for restore?
error23 is described as "file table overflow"

looks like you cannot create more files on the partition where you installed mysql or possibly hit another limit such as the max number of files in the directory

you need to first correct that and then let mysql do its job and you will not use any data
tell us what filesystem you use, but i guess your best bet is start by running the defragmentation tool

i guess it is also likely that you really have a task (or a virus such as nimda) that creates files endlessly : you definitely should find what thes files are
Ensure you’re charging the right price for your IT

Do you wonder if your IT business is truly profitable or if you should raise your prices? Learn how to calculate your overhead burden using our free interactive tool and use it to determine the right price for your IT services. Start calculating Now!

Distinguished Expert 2017

Oops, the innochecksum utility is available on the unix/linuix distro.
mysqlcheck is what available on the windows side.
as the comment http:#a37369004 check where you have mysql installed and then get properties for the data dir.

not sure it is related to a number of files.


I actually added the following to my.ini:

I believe this allowed me to start the MySQLDaemon. I am currently backing up the DB using MySQL Dump.

I am wondering if I can clean the Data directory of the BIN-Logs after this backup is complete?
Distinguished Expert 2017


I am trying to run a MySQL Dump... however, it is failing with the following logs:

120103 17:26:40 [Note] Event Scheduler: Loaded 0 events
120103 17:26:40 [Note] wampmysqld: ready for connections.
Version: '5.5.8-log'  socket: ''  port: 13306  MySQL Community Server (GPL)
120103 17:42:33  InnoDB: Assertion failure in thread 4852 in file ..\..\..\mysql-5.5.8\storage\innobase\btr\btr0cur.c line 4451
InnoDB: Failing assertion: page_no == page_get_page_no(page)
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: about forcing recovery.
120103 17:42:33 - mysqld got exception 0xc0000005 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help diagnose
the problem, but since we have already crashed, something is definitely wrong
and this may fail.

It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 133447 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd: 0x5014fd0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
01488D74    mysqld.exe!?check_next_symbol@Gis_read_stream@@QAE_ND@Z()
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 46CF16C0=SELECT /*!40001 SQL_NO_CACHE */ * FROM `rss`
The manual page at contains
information that should help you find out what is causing the crash.
InnoDB: Thread 1940 stopped in file ..\..\..\mysql-5.5.8\storage\innobase\os\os0sync.c line 813
InnoDB: Thread 7104 stopped in file ..\..\..\mysql-5.5.8\storage\innobase\os\os0sync.c line 474
InnoDB: Thread 5576 stopped in file ..\..\..\mysql-5.5.8\storage\innobase\os\os0sync.c line 474
Distinguished Expert 2017

which my.ini did you setup?
In the example there are different ini files as examples.

Do you have the mysql workbench?
get mysql-front and then run check/repair on the database/tables.

mysqldump databaseofinteret  > database_backup.sql

What command are you running?
Oops, the innochecksum utility is available on the unix/linuix distro.
mysqlcheck is what available on the windows side.

both are available on unix. mysqlcheck is also available on windows, not sure about innochecksum on windows but should exist as well

mysqlcheck only knows how to check and repair myisam tables.
innochecksum only checks innodb pages and i don't believe it repairs anything



this instructs mysql to forget about running transactions but does not adress the problem you have.
if the current transaction cannot complete, the next one possibly will not either


I am wondering if I can clean the Data directory of the BIN-Logs after this backup is complete?

you do not care about binlogs if you do not use replication, which i would assume since you are trying to backup

if you wonder about innodb logs, with the above option you can destroy (or rename) both innnodb logs before startup. mysql will recreate empty logs when it starts. actually, you had better always remove the logs when you use this option.


considering the mysqldump, i believe your innodb engine never managed to start properly.
beware toying with innodb recovery options on a system that has problems already is more than likely to produce data loss, and by that i mean the whole data that innodb holds, espetially if you do not use file_per_table

you have an error that originates from the operationg system, or possibly an intermiediate library between mysql and the OS.
the more you toy with innodb without correcting this error the more likely you will lose your data

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial