Filesystem Review
With boottime reduction in the latter part
Mainstream Filesystem
EXT2
• Crashing between writing file contents and file meta-data may cause
inconsistency of file system, not robust.
EXT3
• Add log function to EXT2
• Still not support capacity compression, space using rate is also low.
ReiserFS
• Logging file system, introduce binary tree structure, faster and high efficiency
in space utilization.
• Incompatible between versions, and doesn’t support long file name (longer
than 768).
JFS
• IBM open source FS, reliable, fast and easy to use, introduce asynchronous
logging instead of logging system.
• Performance not high due to log data writing.
XFS
• Support huge file and directory, excellent I/O, support RAID and LVM.
• Complicate, hard in using.
Benchmark Test
Test settings
* Hardware Processor : Intel Celeron 533
* RAM : 512MB RAM PC100
* Motherboard : ASUS P2B
* Hard drive : WD Caviar SE 160GB (EIDE 100, 7200 RPM, 8MB Cache)
* Controller : ATA/133 PCI (Silicon Image)
* OS Debian Etch (kernel 2.6.15), distribution upgraded on April 18, 2006
* All optional daemons killed (cron,ssh,saMBa,etc.)
* Filesystems Ext3 (e2fsprogs 1.38)
* ReiserFS (reiserfsprogs [Link])
* JFS (jfsutils 1.1.8)
* XFS (xfsprogs 2.7.14)
Description of selected tasks
* Operations on a large file (ISO image, 700MB) Copy ISO from a second disk
to the test disk
* Recopy ISO in another location on the test disk
* Remove both copies of ISO
* Operations on a file tree (7500 files, 900 directories, 1.9GB) Copy file tree
from a second disk to the test disk
* Recopy file tree in another location on the test disk
* Remove both copies of file tree
* Operations into the file tree List recursively all contents of the file tree and
save it on the test disk
* Find files matching a specific wildcard into the file tree
* Operations on the file system Creation of the filesystem (mkfs) (all FS were
created with default values)
* Mount filesystem
* Umount filesystem
The sequence of 11 tasks (from creation of FS to umounting FS) was run as a
Bash script which was completed three times (the average is reported). Each
sequence takes about 7 min. Time to complete task (in secs), percentage of CPU
dedicated to task and number of major/minor page faults during task were
computed by the GNU time utility (version 1.7).
Result
Filesystem Capacity Mount File copy File delete CPU rate File
usage(%) speed(sec) (700M) (700M) (%) Finding
(sec) (sec) (sec)
EXT3 92.77 0.2 38.2 32.5 ~10 4.6
Reiser FS 99.83 2.3 41.8 1.5 ~49 0.8
JFS 99.82 0.2 35.1 0.02 ~10 5
XFS 99.95 0.5 34.8 0.02 ~10 2.8
Other Embedded Filesystem
Comparison
filesystem compress MTD/block writable XIP in-kernel
CRAMFS Y block N N Y
JFFS2 Y MTD Y N Y
YAFFS2 N MTD Y N N
SQUASHFS Y block N N N
LOGFS Y MTD Y N soon
UBIFS Y MTD Y N soon
XIP Y MTD/block N N Y
CRAMFS
AXFS MTD Y N
Note
XIP: execute in place(need no transferring from flash to RAM).
So far SplashTop only support block devices, so we focus on cramfs VS squashfs.
CRAMFS
• File sizes are limited to less than 16MB, maximum filesystem size is a
little over 256MB.
• Read only filesystem.
• Read faster than JFFS2°Cloop.
• Compressing rate larger than 50°.
• Make cramfs:
#mkcramfs /lib [Link]
#mkcramfs /usr [Link]
• Mount cramfs:
#mount –t cramfs [Link] /lib –o loop
#mount –t cramfs [Link] /usr –o loop
Mount Test
Under SplashTop
Test A: mount -t squashfs [Link] /mnt/sq
Test B: mount -o loop -t cramfs [Link] /mnt/cram
Test Result
Mount 1st(sec) 2nd(sec) 3rd(sec) 4th(sec) 5th(sec) 6th(sec) AVG
FS
Cramfs 0. 0. 0. 0. 0. 0. 0.007460432
011893353 005069195 005126116 01269708 004836625 005140224
Squash 0. 0. 0. 0. 0. 0. 0.008707174
022525168 004945227 005091264 00552428 004885443 009271663
Cromfs
• Efficient with gigabytes of large files having lots of redundancy.
• Filesystem is write-once, read-only. It is not possible to append to a
previously-created filesystem, nor it is to mount it read-write.
• cromfs and mkcromfs are slower than their peers.
So cromfs seems not a suitable one for us too.
Mount
Mount filesystem rough
A superblock object is created and initialized via the alloc_super() function.
When mounted, a filesystem invokes this function, reads its superblock off of the
disk, and fills in its superblock object.
Procedure
mount -> sys_mount ° do_mount -> do_kernel_mount -> alloc_vfsmnt & get_sb
(alloc and fill super block) ° sp->s_op->read and other operations.
Boot time boost
• Do it faster
• Do it in parallel
• Do it later
• Don't do it at all
Optimize RC Scripts
Follow the rules listed below to reduce execution time for the init scripts:
• Do not use unnecessary codes in the scripts.
• Replace external commands and utilities with the BusyBox built-ins as far
as possible.
• Do not use the piped commands as far as possible.
• Reduce the number of commands within a pipe.
• Do not use the back-quoted commands as far as possible.
The main goal of such optimization is to reduce the number of the "fork/exec"
calls during a script execution.
Details can be accessed from
[Link]
Reference
[Link]
Linux°°°°°°(ext3,ReiserFS,jfs,xfs)°°°
[Link]
[Link]
°Debian°°°XFS°°°°
[Link]
Filesystems (ext3, reiser, xfs, jfs) comparison on Debian Etch
[Link]
°°°°°°°°XFS-
[Link]
Linux: SquashFS 2.1, Compressed Read Only Filesystem
[Link]
Linux flash °°°°°°
[Link]
Logfs
[Link]
UBI filesystem
[Link]
[Link]
°°°Linux°°°°°°°°°°°°
[Link]
Linux °°°°°°°°
[Link]
°° data page ° Copy-on-Write/XIPs
[Link]
Why ZFS (Zettabyte File System)?
[Link]
Cromfs: Compressed ROM filesystem for Linux (user-space)
[Link]
Benchmarking Filesystems Part II
[Link]
SquashFsComparisons
[Link]
Squashfs LZMA
[Link]
Linux Kernel Development (2nd Edition)
Boot Linux faster
Parallelize Linux system services to improve boot speed
[Link]
lnxw04BootFaster
Reducing OS Boot Times for In-Car Computer Applications, Part III
[Link]
"Reducing OS Boot Times for In-Car Computer Applications, Part II"
"Reducing OS Boot Times for In-Car Computer Applications, Part I"
Boot Times
[Link]
org/Boot_Time#Technologies_and_Techniques_for_Reducing_Boot_Time
Boot-up Time Reduction Howto
[Link]
