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]
Message-ID: <1715214.vxmSNGCbxl@wuerfel>
Date:	Fri, 12 Oct 2012 20:55:02 +0000
From:	Arnd Bergmann <arnd@...db.de>
To:	Theodore Ts'o <tytso@....edu>
Cc:	Lukáš Czerner <lczerner@...hat.com>,
	Jaegeuk Kim <jaegeuk.kim@...sung.com>,
	'Namjae Jeon' <linkinjeon@...il.com>,
	'Vyacheslav Dubeyko' <slava@...eyko.com>,
	'Marco Stornelli' <marco.stornelli@...il.com>,
	'Jaegeuk Kim' <jaegeuk.kim@...il.com>,
	'Al Viro' <viro@...iv.linux.org.uk>,
	gregkh@...uxfoundation.org, linux-kernel@...r.kernel.org,
	chur.lee@...sung.com, cm224.lee@...sung.com,
	jooyoung.hwang@...sung.com, linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH 00/16] f2fs: introduce flash-friendly file system

On Wednesday 10 October 2012 00:53:51 Theodore Ts'o wrote:
> On Tue, Oct 09, 2012 at 01:01:24PM +0200, Lukáš Czerner wrote:
> > Do not get me wrong, I do not think it is worth to wait for vendors
> > to come to their senses, but it is worth constantly reminding that
> > we *need* this kind of information and those heuristics are not
> > feasible in the long run anyway.
> 
> A number of us has been telling flash vendors exactly this.  The
> technical people do seem to understand.  It's management who seem to
> be primarily clueless, even though this information can be extracted
> by employing timing attacks on the media.  I've pointed this out
> before, and the technical people agree that trying to keep this
> information as a "trade secret" is pointless, stupid, and
> counterproductive.  Trying to get the pointy-haired bosses to
> understand may take quite a while.

For eMMC, I think we should start out defaulting to the characteristics
that are reported by the device, because they are usually correct
and those vendors for which that is not true can hopefully
come to their senses when they see how f2fs performs by default.

For USB media, the protocol does not allow you to specify the
erase block size, so we have to guess.

For SD cards, there is a field in the card's registers, but I've
never seen any value in there other than 4 MB, and in most cases
where that is not true, the standard does not allow encoding
the correct amount: it only allows power-of-two numbers up to
4 MB, and typical numbers these days are 3 MB, 6 MB or 8 MB.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ