On Wed, Aug 25, 2010 at 12:22:22PM -0700, Vitali Lovich wrote: > So I've run into this problem where the clock was reset into the 1970s > on my system, causing e2fsck to get confused & think a file I deleted > actually had an orphan list inode pointer stored in the i_dtime > instead of the deletion time, causing e2fsck to get all confused & > return an error code. Are you worried about solving this problem as a one shot deal, or as a long-term design issue. The long-term proper solution is run your clock so it is correct. :-) In the short term, probably the easist thing to do is just run e2fsck -y and let those inodes get populated into lost+found, and then delete them by hands afterwards. For a long-term fix, it probably would make sense to patch ext3/ext4 so that when we delete a file, and the current time is less than number of inodes, that we set dtime to 0xffffffff. > Even a value of midnight 2010 corresponds to a limit of only about 1 > billion files (1 262 304 000). Thus it seems if you delete a file on > a partition with more than a billion files, it will make e2fsck think > you've got a corrupt file-system even though you don't. And if you assuming the smallest possible inode ratio, that's a 4.5TB file. If you use the default inode, that's a 18TB. Ext3 is limited to 16TB, so that's not even an issue.... - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
