On Wed, Aug 25, 2010 at 1:39 PM, Ted Ts'o <tytso@xxxxxxx> wrote: > 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. :-) Right :). The problem is we haven't completely root-caused the issue of why the clock had the wrong time, so I wanted to put in a robust fix that makes the failure-mode more graceful. I don't like using the number of inodes as the threshold since that might change thus getting back to that problem of putting inodes on the orphan list that shouldn't be. > > 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. This is an embedded device - not an option to do anything by hand. When e2fsck fails we assume that there was a catastrophic failure & we brick the device to avoid any potential corruption of user data (this is only when e2fsck fails on the root or boot partitions right after we unmount them after an OS upgrade). > > 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. Is the i_dtime actually used at all? Could we just patch it to always set that as the i_dtime always? I grepped the source, & no one is actually using the i_dtime field. > >> 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.... Depends on the block size, but yes, I don't think this is a super important issue in general with respect to ext2/3 - not sure how this affects ext4 since it, AFAIK, supports much higher capacity partitions. Thanks, Vitali -- 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
