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 Boundary Mobile ⇒ 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 on File 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 Sqlite Video/Image Application - file access - dir operations Memory Management - file indexing and management - security operations Logical File System(ext4, f2fs, btrfs etc..) OS - data operation on Basic File System physical device - buffering if required - no management Device Driver 1 Device Driver 2 Device Driver n Storage 1 Storage 2 Storage n File System - Traditional Layout open(/dir/file) read(file, offset) create(/dir/file) write(file, offset) unlink(/dir/file) Operations Directory Structure File Structure Indexation Space Management Recovery Layout Super Block “/” inode “dir” inode “file” inode Data Loc File System - Basic Types LFS - Log-structured File Systems Image courtsey: http://tinou.blogs.com/.a/6a00d83451ce5a69e2016302fe0458970d-500wi File System - Basic Types COW - Copy On Write Image courtsey: http://dboptimizer.com/wp-content/uploads/2013/06/Screen-Shot-2013-06-03-at-10.28.44-AM.png Test Environment • Hikey - 96Board – 1GB RAM – Cortex-A53 Octa Core – eMMC ( good to have ) http://www.96boards.org/product/hikey/ • 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... 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 Difficult to compare.. So given ranking • Given ranking based on performance for each benchmark and test • Few more points to consider – Performance impact as filesystem ages – CPU utilization Results - iozone average ● Write - btrfs (lzo/zlib) wins ● Read - ext4 performance is comparable to btrfs 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 Lights Though 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/HiKeyGetti ngStarted • 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 .