Menu
▾
▴
#190 dump complains about ext4 inline_data inodes
It look like dump 0.4b52 may have problem with a ext4 inline_data structure. According to CHANGES this should be handled from 0.4b48
Dump small files on ext4 partitions with -O inline-data set.
but still on my ext4 it complains
unexpectedly got EXT4_INLINE_DATA_FL while dumping inode
Thank you for this report. I've discovered that my test for inline_data isn't actually testing inline data. So I will fix the test, and then maybe I'll see this warning.
But when I wrote the code to support inline data I didn't see this message - I think this is harmless - restore should restore the file from the inode, this is dump saying that it didn't expect to be asked to dump inline data separately to the inode - and it appears that I just need to remove that warning.
You should find that restore (full, interactive, incremental and compare), will get this right. I think this is just noise from dump.
Good to hear this should not influence the dump/restore and may be just "harmless" message. From the code this was not obvious. I did not tested the restore thou... I may test it next time. Thanks.
I've now had a chance to investigate this further, and everything is working correctly. The only issue is some noisy logging that needs to be removed.
The code is a bit "funky", though, so I'll add some comments in the next release to explain what's going on. (I wrote this code, then came back to it later and couldn't understand it myself. :-( )
In case you're wondering how it works (you mentioned looking at the code):
In dump/traverse.c, a dummy hole is written as the data in the inode. The file has a non-zero size, but that branch that logs seeing INLINE_DATA doesn't write any data blocks to the tape (correctly, the data is in the inode), which leads to the "deal with holes at the end of inodes" case and results in an inode being written that looks like a completely empty sparse file other than the INLINE_DATA flag that restore then uses to recover the data from the right place.
During restore, the hole is encountered and getfile() is called with xtrnull (a no-op).
The extended attributes are then extracted, with any data in system.data appended to inline_data.
Finally, xtrfile() is called to write the data.
Along with adding the comments, I'll also update those getfile() calls in restore/tape.c to pass xtrnull as the first argument too. As they stand, they look like they're intended to do something, but the callbacks are never actually invoked as the second arg is called for a hole.
I still need the getfile() call (or something similar, getfile() already handles all the necessary logic) to advance to the next block and read the extended attributes. but getfile() also validates that the data is large enough, so the dummy hole keeps everything happy without adding any extra tape overhead or needing any other special case code to read the tape.
This is my wip fix for this: https://sourceforge.net/p/dump/code/ci/7282fcd4616ade29ef664a34c8b70f620407ec96/
(I tend to rebase these wip branches so it might move. The only change you need is the removal of the
msg("Unexpectedly got EXT4_INLINE_DATA_FL while dumping inode %u\n", ino);line in tape/traverse.c