linux-kernel - Re: f2fs tests

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: <1372137203.28480.45.camel@kjgkr>
Date:	Tue, 25 Jun 2013 14:13:23 +0900
From:	Jaegeuk Kim <jaegeuk.kim@...sung.com>
To:	Pavel Machek <pavel@....cz>
Cc:	linux-f2fs-devel@...ts.sourceforge.net,
	kernel list <linux-kernel@...r.kernel.org>
Subject: Re: f2fs tests

Hi,

Thank you for the interest.

2013-06-21 (금), 21:36 +0200, Pavel Machek:
> Hi!
> 
> I played a bit with f2fs...
> 
> First, I had to compile the f2fstools... Unfortunately they require
> never autoconf than available on debian. I tried to hack it, but then
> I decided that compiling it by hand is just simpler.
> 
> gcc -I include/ -I . lib/*.c mkfs/*.c /usr/lib/libuuid.so
> 
> does the trick.
> 
> I was quite surprised there's no fsck in the repository... Do you have
> fsck somewhere?

It'll be available soon via f2fs-tools.git. We've almost done to clean
up the codes. 

> 
> I tested with copy of kernel and 4GB stick (with RedHat logo, thanks
> :-)... copying it from hdd took 46 minutes for VFAT and 19 minutes for
> F2FS. Good.
> 
> VFAT: time find . -name "not-here" took 26 seconds.
> F2F:  time find . -name "not-here" took 22-24 seconds.
> 
> Faster copy, same speed find, good. (Find is even slightly faster than
> HDD, with 27-30 seconds).
> 
> But now the strange stuff: the same data takes 861MB on ext3 and 1.3GB
> on f2fs. (It was even bigger than that on VFAT). I guess I should test
> the patch for inlining small files into inodes?

It is just caused by the different policy to show the file system
utilization.

When you request "df",
1. F2FS shows all the consumed space including its file system metadata.
Instead it tries to show file system size close to the device partiton
size as much as possbile.

2. EXT4 shows the amount of used-made data excluding the reserved space.
Therefore, it shows that its total size is smaller than the underlying
partition size.

So, you need to compare each entries from the results of "df" at a same
time.

When I tested 8GB partition,

F2FS shows:  [Size]   [Used]    [Avail]
 1. empty:    8.0G     497M       7.5G
 2. cp   :    8.0G     594M       7.4G
 3. untar:    8.0G     1.3G       6.7G

EXT4 shows:
 1. empty:    7.8G     18M        7.4G
 2. cp   :    7.8G    116M        7.3G
 3. untar:    7.8G    794M        6.6G 

So, after untar the kernel source, you're able to discover that the
available sizes are not much different between F2FS and EXT4.

Thanks,

> 
> 									Pavel

-- 
Jaegeuk Kim
Samsung

--
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/