Re: [PATCH -v2] ext4: avoid reusing recently deleted inodes in no journal mode
From: Andrew Morton <akpm@linux-foundation.org>
Date: 2013-08-08 00:03:29
On Fri, 26 Jul 2013 15:32:43 -0400 "Theodore Ts'o" [off-list ref] wrote:
In no journal mode, if an inode has recently been deleted, we shouldn't reuse it right away. Otherwise it's possible, after an unclean shutdown, to hit a situation where a recently deleted inode gets reused for some other purpose before the inode table block has been written to disk. However, if the directory entry has been updated, then the directory entry will be pointing at the old inode contents.
Sounds a bit hacky :(
quoted hunk ↗ jump to hunk
E2fsck will make sure the file system is consistent after the unclean shutdown. However, if the recently deleted inode is a character mode device, or an inode with the immutable bit set, even after the file system has been fixed up by e2fsck, it can be possible for a *.pyc file to be pointing at a character mode device, and when python tries to open the *.pyc file, Hilarity Ensues. We could change all of userspace to be very suspicious about stat'ing files before opening them, and clearing the immutable flag if necessary --- or we can just avoid reusing an inode number if it has been recently deleted.--- a/fs/ext4/ialloc.c +++ b/fs/ext4/ialloc.c@@ -625,6 +625,51 @@ static int find_group_other(struct super_block *sb, struct inode *parent, } /* + * In no journal mode, if an inode has recently been deleted, we want + * to avoid reusing it until we're reasonably sure the inode table + * block has been written back to disk. + */ +int recently_deleted(struct super_block *sb, ext4_group_t group, int ino) +{ + struct ext4_group_desc *gdp; + struct ext4_inode *raw_inode; + struct buffer_head *bh; + unsigned long dtime, now; + int inodes_per_block = EXT4_SB(sb)->s_inodes_per_block; + int offset, ret = 0, recentcy = 30;
The version in linux-next is different from this. it uses + int offset, ret = 0, recentcy = dirty_expire_interval; which breaks the build because dirty_expire_interval isn't exported to modules. Good luck fixing this without adding a bisection hole :( Also, it's spelled "recency"! What's the rationale for using this anyway? Seems a bit arbitrary. Wouldn't using the ext4 commit interval be more appropriate?