lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 25 Aug 2010 16:39:14 -0400
From:	Ted Ts'o <tytso@....edu>
To:	Vitali Lovich <vlovich@...il.com>
Cc:	linux-ext4@...r.kernel.org
Subject: Re: question about i_dtime being used as an orphan list pointer

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ