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:	Tue, 10 Apr 2012 08:40:11 +0000
From:	Arnd Bergmann <arnd@...db.de>
To:	Minchan Kim <minchan@...nel.org>
Cc:	정효진 <syr.jeong@...sung.com>,
	"'Alex Lemberg'" <Alex.Lemberg@...disk.com>,
	linaro-kernel@...ts.linaro.org, "'Rik van Riel'" <riel@...hat.com>,
	linux-mmc@...r.kernel.org, linux-kernel@...r.kernel.org,
	"'Luca Porzio (lporzio)'" <lporzio@...ron.com>, linux-mm@...ck.org,
	kernel-team@...roid.com, "'Yejin Moon'" <yejin.moon@...sung.com>,
	"'Hugh Dickins'" <hughd@...gle.com>,
	"'Yaniv Iarovici'" <Yaniv.Iarovici@...disk.com>, cpgs@...sung.com
Subject: Re: swap on eMMC and other flash

On Tuesday 10 April 2012, Minchan Kim wrote:
> I think it's not good approach.
> How long does it take to know such parameters?
> I guess it's not short so that mkfs/mkswap would be very long
> dramatically. If needed, let's maintain it as another tool.

I haven't come up with a way that is both fast and reliable.
A very fast method is to time short read requests across potential
erase block boundaries and see which ones are faster than others,
this works on about 3 out of 4 devices. 

For the other devices, I currently use a fairly manual process that
times a lot of write requests and can take a long time.

> If storage vendors break such fields, it doesn't work well on linux
> which is very popular on mobile world today and user will not use such
> vendor devices and company will be gone. Let's give such pressure to
> them and make vendor keep in promise.

This could work for eMMC, yes.

The SD card standard makes it impossible to write the correct value for
most devices, it only supports power-of-two values up to 4MB for SDHC,
and larger values (I believe 8, 12, 16, 24, ... 64) for SDXC, but a lot
of SDHC cards nowadays use 1.5, 3, 6 or 8 MB erase blocks.

	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