linux-ext4 - Re: [GIT PULL] ext4 bug fixes for 3.18

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20141101182950.GC31245@thunk.org>
Date:	Sat, 1 Nov 2014 14:29:50 -0400
From:	Theodore Ts'o <tytso@....edu>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>
Subject: Re: [GIT PULL] ext4 bug fixes for 3.18

> And your point about >16TB filesystems is completely buggy. That was
> *my* point. Most people - even on 64-bit - do *not* have 16TB
> filesystems, and the high 32 bits are zero or contain very very little
> information (ie even on a multi-terabyte filesystem, it's one or two
> bits worth of information). So hash_32() is not only much more
> reasonable on a 32-bit machine, the end result is basically as good
> for 99.999% of all uses. Exactly *because* people don't have those big
> filesystems.

I agree; that's why I suggested using hash_32() if the number of
blocks in the file system is less than 2**32.  I did look at hash_u64
and didn't think it was that bad, but that's probably because compared
to crypto checksums it's positively fast, and it's really easy to get
into the bad habit of thinking that all the world's an x86_64.  :-)

     	     	      	       	    	- 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