Android and File System Chemistry

- Satish Patel

About Me !

• Satish Patel• An Android Engineer at Linaro

• Area of interest at present - Android Optimization and Enhancement

Before we begin.. Why Android ??

Gartner says..

Industry Shift..Desktop == > Touch Interface

No more User Experience == > It’s User Demands

Android BoundaryMobile ⇒ Non Mobile

Mobile

Everywhere

And we already know..!!

• Android is an Open Source (Apache based)

• Built in connectivity solution (BT, Wifi, USB, Sensor etc..)

• Community - A most powerful factor

Challenges.. To align the shift.. The Android Boundary:mobile -> non-mobile

Challenges

• Meeting segment requirements ( low storage, low bandwidth, frequents disk i/o etc..)

• Memory optimization (some device has low RAM & storage)

• Speed optimization (read/write)

• Use case driven- portability

Study onFile System Chemistry with Android

Performance of a smartphone is not governed by the speed of its internet but rather by the storage performance

File System - Traditional Layout

WebKit

Memory Management

Logical File System(ext4, f2fs, btrfs etc..)

Basic File System

Device Driver 1 Device Driver 2 Device Driver n

Storage 1 Storage 2 Storage n

Application

OS

- file access- dir operations- file indexing and management- security operations

- data operation on physical device- buffering if required- no management

Video/ImageSqlite

File System - Traditional Layout

Directory Structure

Indexation Space Management

File Structure

Recovery

open(/dir/file)create(/dir/file)unlink(/dir/file)

read(file, offset)write(file, offset)

Operations

Super Block “/” inode “dir” inode “file” inode Data Loc

Layout

File System - Basic Types

Image courtsey: http://tinou.blogs.com/.a/6a00d83451ce5a69e2016302fe0458970d-500wi

LFS - Log-structured File Systems

File System - Basic Types

Image courtsey: http://dboptimizer.com/wp-content/uploads/2013/06/Screen-Shot-2013-06-03-at-10.28.44-AM.png

COW - Copy On Write

Test Environment

• Hikey - 96Board– 1GB RAM

– Cortex-A53 Octa Core

– eMMC ( good to have )• Popular on embedded Device

• Cheap & Flexible

• Fast read & random seek

• Domains - navigation, eReaders, smartphones, industrial loggers, entertainment devices etc..

• AOSP + Linaro PatchSet (branch : r55, kernel 4.4)

• F2FS, Ext4, Squashfs, btrfs etc...

http://www.96boards.org/product/hikey/

File System - ext4

• Most used linux file system

• Max File size - 16 TiB

• Supports - encryption

• Use “extent (large allocation)” instead block mapping

– A single extent in ext4 can map up to 128 MiB of contiguous space with a 4 KiB block size

• “secure deletion” - still under discussion

File System - f2fs• F2FS: Flash-Friendly File System

• Introduced by Samsung Electronics

• Max file size - 3.94 TiB

• F2FS make use of flash translation layer (FTL)– Controller does job of logical to physical mapping

– Takes care of wear-leveling, garbage collection

• F2FS cleaning - on demand and in the background

• Log-structured file system

• Few crashes observed

Filesystem - btrfs

• Btrfs: B-Tree File System (butter/better/b-tree)

• Efficient n-array data structure (B Tree)

• COW - Copy On Write mechanism

– Lazy way to keep track of data by delaying read/write

• Like ext4, use “extent”

• Default filesystem for SUSE Linux Enterprise Server 12

• Make use of compression algorithms for data

Filesystem - btrfs

• ZLIB -- slower, higher compression ratio (compress=zlib)

• LZO -- faster compression and decompression than zlib, low compression ratio, designed to be fast (compress=lzo)

• LZO seems to give satisfying results for general use - again depends on data set

• LZ4 Compression - for better compression, but not likely to be mainline

File System - nilfs• B-tree based file management

• Continuous snapshotting : Quick recovery after crash

• Log-structured file system

• Reduce seek time

FileSystem - squashfs

• Compressed Read only file system• Suitable for “/system” partition• Used in live CDs (ubuntu, Fedora, Mint etc..)

Benchmarks

• Vellamo, redlicense, androbench

• Bonnie (ported for Android)

• Iozone (ported for Android)

• Overload and long run test - in progress!!

Challenges

• Fixed build support for f2fs image generation (core.mk & image size alignment to 4096)

• Fixed sparse raw image generation issue – Need to use for btrfs and nilfs

• Image generation for btrfs, nilfs, squashfs etc..

• Benchmark porting - bonnie, iozone

• Partition overload script and long run impact script

Results

• Given ranking based on performance for each benchmark and test

• Few more points to consider– Performance impact as filesystem ages

– CPU utilization

Difficult to compare.. So given ranking

● Write - btrfs (lzo/zlib) wins● Read - ext4 performance is

comparable to btrfs

Results - iozone average

Results - read/write (64K)

● Small records/file F2FS wins with sync option● For read NILFS has better performance cache read

Results - read/write (1MB - 4Kreclen)

● Ext4 perform good on all read operations● F2FS has good write score

Results - read/write (512MB, 4MB)

● Write - btrfs (lZO)● Small file read EXT4● With sync - zlib wins.. But looks like there is a

cache ??

Results - Bonnie

● Btrfs (lzo) gives good number but.. ○ At the cost of CPU eating.. ○ No of kworker threads are more.. Coming

up next● F2FS/Ext has fair amount of CPU usage on

read/write

BTRFS - Low LightsThough BTRFS has good performance

• High CPU Utilization: More kernel threads

• For small file (<1MB), btrfs under perform over f2fs and ext4. Not recommended where small i/o transaction with sync is expected. E.g. frequent calls to DB entries.

• Btrfs does not force all dirty data to disk on every fsync or O_SYNC operation ( risk on power/crash recovery)

• Yet to test effect on long run test ??

Results - hdparm

● Squashfs is better ( after btrfs )

Conclusion• Benchmark numbers are cross verified with available results

(other desktop system with 4.4 kernel) on

– https://openbenchmarking.org

– Comparative results are almost matching w.r.t each file system ( considering file size and record len)

Conclusion• BTRFS : Large file + large RAM ( as it use buffered i/o)

– In flight entertainment system ( mostly read on movies/songs/images etc..)

– Portable streaming devices (plugged into TV or other display)

• F2FS/Ext4 : Small File + Small RAM + DB Access with disk integrity

– Industrial monitoring system, Consumer Phone, Health monitoring system

• NilFS : Small File + Small RAM + Buffered read operations

Conclusion• F2FS/NilFS : Shows good write performance (small file)

– Good for flash based storage.

• SquashFS : Good buffered I/O read

– Use for read only partition ( system libraries and ro database)

TODO List• Perform long run test (3-4 days, with various operations) and

measure the impact

• Partition overload testing - impact on low disk availability

• Encryption impact

• Check BTRFS performance on latest kernel

• Write + fysnc() results

References• https://btrfs.wiki.kernel.org

• https://github.com/96boards/documentation/wiki/HiKeyGettingStarted

• https://git.linaro.org/people/satish.patel/android-bonnie.git

• https://www.usenix.org/system/files/conference/atc13/atc13-jeong.pdf

• https://android-git.linaro.org