|
As yet, I haven't been able to reproduce this problem, but I've been investigating the code to see if the bug can be found this way.
Looking into e2fsck/pass1.c::check_blocks() it is adding directories with 3 or more blocks but no EXT2_INDEX_FL into the "rehash" list, even if the -D option is not specified. This means that corrupted object directories, or directories modified during e2fsck that have the EXT2_INDEX_FL cleared will be rehashed automatically. This is not the same as the -D flag, since it does not attempt to pack/rehash existing directories that already have the EXT2_INDEX_FL set, which would make up the majority of directories.
The e2fsck_rehash_dir() first reads all directory entries into memory, hashes them and sorts by the hash, then calls write_directory() to allocate new directory blocks (if needed) to cover the directory entries, and calls ext2fs_block_iterate3->write_dir_block() to iterate over the directory entries and pack them into blocks, writing each one into the previously-allocated blocks of the directory. Once all of the blocks have been written, the remaining blocks of the file are freed from the filesystem by write_dir_block(), and finally updates the inode with the new block count. I don't yet see where the block count of the file is reduced.
|
|
I was able to reproduce this problem with an e2fsck test script (attached) when shrinking an htree extent directory with only 3 index blocks referenced directly by the inode. The problem is not present on block-mapped directories but looks to be a danger for any user of the "-fD" option with extent-mapped directories.
It looks like the problem is if the inode shrinks enough that one of the index blocks is dropped from the end of the file (blocks after logical block 114 were freed), but the write_directory() write_dir_block() iterator doesn't free the index block 800:
The extent tree now has a bogus index block at the end, but somehow is
also missing the valid extent block that was holding the rest of the
file, as shown by debugfs (after "e2fsck -fD" but before the second
e2fsck that detects the corruption) and logical blocks 83-114 are lost:
debugfs: stat subdir
Inode: 12 Type: directory Mode: 0755 Flags: 0x81000
Generation: 0 Version: 0x00000000
User: 0 Group: 0 Size: 117760
File ACL: 0 Directory ACL: 0
Links: 2 Blockcount: 238
Fragment: Address: 0 Number: 0 Size: 0
ctime: 0x5642e764 -- Tue Nov 10 23:59:48 2015
atime: 0x5642e764 -- Tue Nov 10 23:59:48 2015
mtime: 0x5642e764 -- Tue Nov 10 23:59:48 2015
EXTENTS:
(ETB0):146, (0):129, (1):133, (2):137, (3):141, (4):145, (5):150,
(6):154, (7):158, (8):162, (9):166, (10):170, (11):174, (12):178,
(13):182, (14):186, (15):190, (16):194, (17):198, (18):202,
(19):206, (20):210, (21):214, (22):218, (23):222, (24):226,
(25):230, (26):234, (27):238, (28):242, (29):246, (30):250,
(31):254, (32):258, (33):262, (34):266, (35):270, (36):274,
(37):278, (38):282, (39):286, (40):290, (41):294, (42):298,
(43):302, (44):306, (45):310, (46):314, (47):318, (48):322,
(49):326, (50):330, (51):334, (52):338, (53):342, (54):346,
(55):350, (56):354, (57):358, (58):362, (59):366, (60):370,
(61):374, (62):378, (63):382, (64):386, (65):390, (66):394,
(67):398, (68):402, (69):406, (70):410, (71):414, (72):418,
(73):422, (74):426, (75):430, (76):434, (77):438, (78):442,
(79):446, (80):450, (81):454, (82):458, (ETB0):800, (172):814
The i_size is correct for 115 data blocks written, and i_blocks would
be correct if the second index block wouldn't have been lost. It seems
the bug is in the extent handling code, but I haven't yet dug into why
the last extent is kept. I tried deleting it like the other blocks,
but the iteration immediately stops with an error that the index block
is corrupted.
|
LU7381-ost_scratch_61-d0.tar.gz
LU7381-ost_scratch_73-dump_htree.tar.gz