Details
-
Bug
-
Status: Closed (View Workflow)
-
Minor
-
Resolution: Fixed
-
5.5.36, 10.0.8
-
None
-
None
-
Fusion-IO SSD
Description
Currently size is set like:
current_size = 0;
desired_size = (ib_int64_t)size + (((ib_int64_t)size_high) << 32);
#ifdef HAVE_POSIX_FALLOCATE
if (srv_use_posix_fallocate) {
if (posix_fallocate(file, current_size, desired_size) == -1) {
Thus file size is always extended from offset 0 to desired offset. This is clearly slower than doing
posix_fallocate(real_current_size, desired_size)
Attachments
Issue Links
- relates to
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
Activity
revno: 4008
branch nick: 10.0
message:
MDEV-5746: Slow file extend when innodb_use_fallocate=1 and SSD
file storage.
Analysis: posix_fallocate was called using 0 as offset and len as
desired size. This is not optimal for SSDs.
Fix: Call posix_fallocate with correct offset i.e. current file size
and extend the file from there len bytes.
In the 5.5 version of this change we are incorrectly extending the file to current_size+desired_size bytes (if we ignore the fact that the start_offset calculation does not work for file_start_page_no>0). The third argument of posix_fallocate() is supposed to be the length by which the file is to be extended, not the total size.
This bug was not propagated to 10.0, because the posix_fallocate() call was first introduced into 10.0 in MDEV-5878 in this commit.
In my third 5.5 commit of MDEV-11520 I believe I have fixed all issues with the posix_fallocate() call in fil_extend_space_to_desired_size().
revno: 4098
message:
MDEV-5746: Slow file extend when innodb_use_fallocate=1 and SSDfile storage.
Analysis: posix_fallocate was called using 0 as offset and len as
desired size. This is not optimal for SSDs.
Fix: Call posix_fallocate with correct offset i.e. current file size
and extend the file from there len bytes.