linux-kernel - Re: [PATCH 00/16 v3] f2fs: introduce flash-friendly file system

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] [thread-next>] [day] [month] [year] [list]

Message-Id: <201211102149.48946.arnd@arndb.de>
Date:	Sat, 10 Nov 2012 21:49:48 +0000
From:	Arnd Bergmann <arnd@...db.de>
To:	Martin Steigerwald <Martin@...htvoll.de>
Cc:	linux-kernel@...r.kernel.org, Kim Jaegeuk <jaegeuk.kim@...il.com>,
	Jaegeuk Kim <jaegeuk.kim@...sung.com>,
	linux-fsdevel@...r.kernel.org, gregkh@...uxfoundation.org,
	viro@...iv.linux.org.uk, tytso@....edu, chur.lee@...sung.com,
	cm224.lee@...sung.com, jooyoung.hwang@...sung.com
Subject: Re: [PATCH 00/16 v3] f2fs: introduce flash-friendly file system

On Saturday 10 November 2012, Martin Steigerwald wrote:
> Command (m for help): n
> Partition type:
>    p   primary (0 primary, 0 extended, 4 free)
>    e   extended
> Select (default p): p
> Partition number (1-4, default 1): 1
> First sector (2048-4095998, default 2048): 
> Using default value 2048
> Last sector, +sectors or +size{K,M,G} (2048-4095998, default 4095998): 
> Using default value 4095998

This is almost certainly not the right setting for f2fs, which only works
at its design point if the segments are aligned to erase blocks. All modern
flash devices have erase blocks larger than 1 MB, so starting the partition
at a 1 MB offset will cause it to be misaligned. Also, some USB sticks
have an area optimized for random writes in the beginning of the drive
where both FAT32 and f2fs store their metadata. It may be worth testing
again without a partition table, using just the raw device.

I would also recommend using flashbench to find out the optimum parameters
for your device. You can download it from
git://git.linaro.org/people/arnd/flashbench.git
In the long run, we should automate those tests and make them part of
mkfs.f2fs, but for now, try to find out the erase block size and the number
of concurrently used erase blocks on your device using a timing attack
in flashbench. The README file in there explains how to interpret the
results from "./flashbench -a /dev/sdb  --blocksize=1024" to guess
the erase block size, although that sometimes doesn't work.

With the correct guess, compare the performance you get using

$ ERASESIZE=$[2*1024*1024] # replace with guess from flashbench -a
$ ./flashbench /dev/sdb --open-au --open-au-nr=1 --blocksize=4096 --erasesize=${ERASESIZE}
$ ./flashbench /dev/sdb --open-au --open-au-nr=3 --blocksize=4096 --erasesize=${ERASESIZE}
$ ./flashbench /dev/sdb --open-au --open-au-nr=5 --blocksize=4096 --erasesize=${ERASESIZE}
$ ./flashbench /dev/sdb --open-au --open-au-nr=7 --blocksize=4096 --erasesize=${ERASESIZE}
$ ./flashbench /dev/sdb --open-au --open-au-nr=13 --blocksize=4096 --erasesize=${ERASESIZE}

The first one of those should always be the fastest, hopefully followed by
some that are equally fast and then some much slower ones (especially for the
smaller block sizes). The "active_logs=N" mount option should be one less
than the highest number above that is still "fast", and only "2", "4" and "6"
are valid at the moment. If you are lucky, your device is still fast with
"--open-au-nr=7" and slow only for higher numbers, then the default of "6"
is ok.

If the erase size is larger than 2 MB, then you have to "-s" option in
mkfs.f2fs to configure how many 2 MB segments there are in one erase block.
For a 2 GB USB stick, I would guess that the erase block size is 1, 2 or
4 MB. Newer (larger) sticks will have larger erase blocks that may also
be a multiple of 3 MB (3, 6, 12, or 24).

	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/