Details
-
Bug
-
Status: Closed (View Workflow)
-
Minor
-
Resolution: Fixed
-
10.0.11, 10.1.0, 10.2.0, 10.3.0, 10.4.0, 10.5.0, 5.5(EOL)
-
None
Description
"InnoDB: using atomic writes." is always printed, with fprintf, different in formatting to anything else.
The message is misleading.
Note, that neither I chose the page size to be 4K, nor do I have 4K sectors on the disk here,
which would be prerequisite of atomic writes (on Windows)
InnoDB: using atomic writes.
|
2020-07-02 23:18:26 0 [Note] InnoDB: Mutexes and rw_locks use Windows interlocked functions
|
2020-07-02 23:18:26 0 [Note] InnoDB: Uses event mutexes
|
2020-07-02 23:18:26 0 [Note] InnoDB: Compressed tables use zlib 1.2.11
|
2020-07-02 23:18:26 0 [Note] InnoDB: Number of pools: 1
|
2020-07-02 23:18:26 0 [Note] InnoDB: Using SSE2 crc32 instructions
|
2020-07-02 23:18:26 0 [Note] InnoDB: Initializing buffer pool, total size = 16M, instances = 1, chunk size = 16M
|
2020-07-02 23:18:26 0 [Note] InnoDB: Completed initialization of buffer pool
|
2020-07-02 23:18:26 0 [Note] InnoDB: Starting crash recovery from checkpoint LSN=300288
|
2020-07-02 23:18:26 0 [Note] InnoDB: 128 out of 128 rollback segments are active.
|
2020-07-02 23:18:26 0 [Note] InnoDB: Removed temporary tablespace data file: "ibtmp1"
|
2020-07-02 23:18:26 0 [Note] InnoDB: Creating shared tablespace for temporary tables
|
2020-07-02 23:18:26 0 [Note] InnoDB: Setting file 'C:\xampp\mysql\data\ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...
|
2020-07-02 23:18:26 0 [Note] InnoDB: File 'C:\xampp\mysql\data\ibtmp1' size is now 12 MB.
|
2020-07-02 23:18:26 0 [Note] InnoDB: Waiting for purge to start
|
2020-07-02 23:18:26 0 [Note] InnoDB: 10.4.13 started; log sequence number 300297; transaction id 171
|
2020-07-02 23:18:26 0 [Note] InnoDB: Loading buffer pool(s) from C:\xampp\mysql\data\ib_buffer_pool
|
2020-07-02 23:18:26 0 [Note] Plugin 'FEEDBACK' is disabled.
|
2020-07-02 23:18:26 0 [Note] Server socket created on IP: '::1'.
|
2020-07-02 23:18:26 0 [Note] InnoDB: Buffer pool(s) load completed at 200702 23:18:26
|
Attachments
Issue Links
- is caused by
-
MDEV-4338 Support FusionIO/directFS atomic writes.
-
- Closed
-
Activity
I think you need to fix it for when it was introduced outside of Fusion IO.
This message used to pop up, when innodb_use_atomic_writes was set to on, but after you removed it from MariaDB 10.3.0, this popped up on Windows.
The thing is Innodb is NOT using atomic writes, but it says it does. In the past it at least would complain if you tried to use them, and it did not work.
wlad, indeed, the message is misleading. Even if the global variable srv_use_atomic_writes were set, we would still invoke my_test_if_atomic_write() to check if writes are atomic with a particular page size.
When using the default innodb_page_size=16k, page writes should be atomic on NTFS when using ROW_FORMAT=COMPRESSED and KEY_BLOCK_SIZE<=4.
I think that we must also remove some other nonsense, because innodb_file_per_table is a dynamic parameter.
diff --git a/storage/innobase/handler/ha_innodb.cc b/storage/innobase/handler/ha_innodb.cc
|
index 144f9951eb0..160eb329cc7 100644
|
--- a/storage/innobase/handler/ha_innodb.cc
|
+++ b/storage/innobase/handler/ha_innodb.cc
|
@@ -4316,14 +4316,8 @@ innobase_init(
|
|
srv_use_atomic_writes
|
= innobase_use_atomic_writes && my_may_have_atomic_write;
|
- if (srv_use_atomic_writes && !srv_file_per_table)
|
- {
|
- fprintf(stderr, "InnoDB: Disabling atomic_writes as file_per_table is not used.\n");
|
- srv_use_atomic_writes= 0;
|
- }
|
|
if (srv_use_atomic_writes) {
|
- fprintf(stderr, "InnoDB: using atomic writes.\n");
|
/*
|
Force O_DIRECT on Unixes (on Windows writes are always
|
unbuffered) |
Page writes can only be atomic on Windows (they do not mention NTFS 
) if the write is the size of a sector, which leaves the single possibility with innodb page size = 4K and disk sector = 4K
Furthermore, the documentation string of innodb_use_atomic_writes was referring to deprecated options. I corrected that.
I think that we should probably deprecate and ignore this parameter, and just make use of atomic writes when they are available.
I agree that we should just do atomic writes (i.e skip doublewrite), if atomic is detected.
wlad, on 10.2 and 10.3, it seems to me that my_may_have_atomic_write should always be 0 on other systems than Linux. It is unclear to me how that message could have been output on Microsoft Windows.
It turns out that the message output has not been changed ever since you introduced it in
MDEV-4338. Please fix it as you see fit.