[MDEV-29191] Use statx/btime instead of stat/ctime for CREATE_DATE where available Created: 2022-07-28 Updated: 2022-08-03 |
|
| Status: | Open |
| Project: | MariaDB Server |
| Component/s: | Data Definition - Alter Table, Information Schema, Storage Engine - InnoDB |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major |
| Reporter: | Hartmut Holzgraefe | Assignee: | Unassigned |
| Resolution: | Unresolved | Votes: | 1 |
| Labels: | None | ||
| Issue Links: |
|
||||||||
| Description |
|
Currently the CREATE_TIME column in SHOW TABLE STATUS output and in INFORMATION_SCHEMA.TABLES is populated from file system ctime information returned by the stat() system call. ctime does not really contain a files creation time, but rather the last time the files metadata got changed. As this is often not changed after a file got created it may show the creation time, but it is not guaranteed. Newer file systems like e.g. ext4 add another time field for the actual creating time, often also named birth time / btime. This additional field is available via the newer statx() variant of the classic stat() system call. So the feature request is to use statx() instead of stat() where it is available, and to populate CREATE_TIME with the btime value if set, and to only fall back to ctime where btime is not available. See also e.g.: https://man7.org/linux/man-pages/man2/statx.2.html |
| Comments |
| Comment by Marko Mäkelä [ 2022-08-03 ] |
|
I do not think that this would necessarily help much. As per MDEV-29200, a problematic scenario is that ALTER TABLE will create a new .frm file, even for something that does not change the table definition (ALTER TABLE t1 RENAME TO t2). Because InnoDB does not keep track of any creation date itself, it will try to retrieve one from the .frm file. The way how ALTER TABLE is implemented would always ruin that file’s creation timestamp, by actually creating a new file, even though the table itself did not change. I think that the .frm file had better store the create time explicitly, possibly along with the time of the last ALTER TABLE operation. |
| Comment by Hartmut Holzgraefe [ 2022-08-03 ] |
|
Yes, having table creation and last modification time stored in the .frm file itself would for sure be better. This ticked is not about the MariaDB server itself changing the .frm files ctime, it is about external tools doing so, like e.g. some file system level backup tools seem to do. |