Advanced UNIX File Systems
Berkley Fast File System,
Logging File System,
Virtual File Systems
Classical Unix File System
•
Traditional UNIX file system keeps I-node information separately from the data blocks; Accessing a
file involves a long seek from I-node to the data.
•
Since files are grouped by directories, but I-nodes for the files from the same directory are not
allocated consecutively, non-consecutive block reads are long.
•
Allocation of data blocks is sub-optimal because often next sequential block is on different cylinder.
•
Reliability is an issue, cause there is only one copy of super-block, and I-node list;
•
Free blocks list quickly becomes random, as files are created and destroyed
•
Randomness forces a lot of cylinder seek operations, and slows down the performance;
•
There was no way to “defragment” the file system. Dump, redefine, restore required.
•
Due to small block size (512-1024), many random blocks, many reads, files too small, low
bandwidth utilization on system bus..
Berkeley Fast File System (FFS)
•
BSD Unix did a redesign in mid 80s that they called the Fast File System (FFS)
McKusick, Joy, Leffler, and Fabry.
•
Improved disk utilization, decreased response time
•
Minimal block size is 4096 bytes allows to files as large as 4G to be created with only 2
levels of indirection.
•
Disk partition is divided into one or more areas called cylinder groups;
Data Block and INODE
Placement
•
The original Unix FS had two placement problems:
Data blocks allocated randomly in aging file systems
- Blocks for the same file allocated sequentially when FS is new
- As FS “ages” and fills, need to allocate into blocks freed up when other files are deleted
- Deleted files essentially randomly placed So, blocks for new files become scattered
across the disk.
INODEs allocated far from data blocks
- All inodes at beginning of disk, far from data
- Traversing file name paths, manipulating files, directories requires going back and
forth from inodes to data blocks
•
FRAGMENTATION. Both of these problems generate many long seeks (100X slower
than sequential read)
Cylinder Groups
•
BSD FFS addressed these problems using the notion of a cylinder group
- Disk partitioned into groups of cylinders
- Data blocks in same file allocated in same cylinder
- Files in same directory allocated in same cylinder
- Inodes for files allocated in same cylinder as file data blocks
- Minimize seek times
•
Free space requirements
- To be able to allocate according to cylinder groups, the disk must have free space
scattered across cylinders
- 10% of the disk is reserved just for this purpose (root)
- Only used by root – why it is possible for “df” to report >100%. And why a filesystem
is “full” at 90%.
Cylinder Groups
•
Each cylinder group is one or more consecutive cylinders on a disk.
•
Each cylinder group contains a redundant copy of the super block, and I-node
information, and free block list pertaining to this group.
•
Each group is allocated a static amount of I-nodes.
•
The default policy is to allocate one I-node for each 2048 bytes of space in the cylinder
group on the average.
•
The idea of the cylinder group is to keep I-nodes of files close to their data blocks to
avoid long seeks; also keep files from the same directory together.
•
BFFS uses varying offset from the beginning of the group to avoid having all crucial
data on one place
•
The offset differs between the beginning and the information is used for data blocks.
Cylinder Groups
File System Block Size
•
Problem: Small blocks (1K) cause two problems:
-Low bandwidth utilization
- Small max file size (function of block size)
FFS Solution: use a larger block (4K).
- Very large files, only need two levels of indirection for 2^32
- Improved bandwidth. As block size increases the efficiency of a single transfer also
increases, and the space taken up by I-nodes and block lists decreases.
•
Problem: as block size increases, the space is wasted due to internal fragmentation.
FFS Solution: introduce “fragments” (1K pieces of a block)
- Divide block into fragments;
- Each fragment is individually addressable;
- Fragment size is specified upon a file system creation;
- The lower bound of the fragment size is the disk sector size;
•
Problem: Media failures
FFS Solution: Replicate superblock, subdivide INODE list, directory entries among
cylinder groups
•
Problem: Device oblivious
FFS Solution: Parameterize FS according to device characteristics (see “smart” disk
drives).
File System Integrity
•
Due to hardware failures, or power failures, file system can potentially enter an
inconsistent state.
•
Metadata (e.g., directory entry update, I-node update, free blocks list updates, etc.)
should be synchronous, cache operations (write through).
•
A specific sequence of operations also matters. We cannot guarantee that the last
operation does not fail, but we want to minimize the damage, so that the file system can
be more easily restored to a consistent state.
•
Consider file creation:
– write directory entry, update directory I-node, allocate I-node, write allocated I-node
on disk, write directory entry, update directory I-node.
– But what should be the order of these synchronous operations to minimize the damage
that may occur due to failures?
•
Correct order is:
1) allocate I-node (if needed) and write it on disk;
2) update directory on disk;
3) update I-node of the directory on disk.
FFS Considerations
•
Synchronous operations for updating the metadata:
– Should be synchronous, thus need seeks to I-nodes;
– In BFFS is not a great problem as long as files are relatively small, cause directory,
file data blocks, and Inodes should be all in the same cylinder group.
•
Write-back of the dirty blocks:
– Because the file access pattern is random different applications use different files at
the same time, and the dirty blocks are not guaranteed to be in the same cylinder group.
•
Still more problems with FFS:
- With cylinder groups or extent allocation, data placement is improved, but still have
many small seeks possibly related files are physically separated
- nodes separated from files (small seeks)
- directory entries separate from inodes
- Metadata requires synchronous writes: with small files, most writes are to metadata
(synchronous) and synchronous writes very slow;
•
Solution: Logging File System, concept everything is log – including metadata. Think
database transaction recovery log. Everything written as a sequential log entry.
FFS Problems – LFS Solutions
•
Problem: while caching is enough for good read performance. Writes are the real
performance bottleneck. Writing-back cached user blocks may require many random
disk accesses. Write-through for metadata reliability denies optimizations.
Solution: Logging, Each write - both data and control – is appended to the end of the
sequential log.
•
Problem: how to locate files and data efficiently for random access by reads
Solution: use a floating file map (virtual journal in memory).
•
Problem: FFS uses inodes to locate data blocks
- Inodes pre-allocated in each cylinder group
- Directories contain locations of inodes
LFS appends inodes to end of the log just like data. BUT, it makes them hard to find.
Solution:
- Use another level of indirection: Inode maps
- Inode maps map file #s to inode location
- Location of inode map blocks kept in checkpoint region
- Checkpoint region has a fixed location
- Cache inode maps in memory for performance
Logging File System (LFS)
•
Logging File Systems Developed by Ousterhout & Douglis (1992)
•
LFS treats the disk as a single log for appending
•
All info written to disk is appended to log
- Data blocks, attributes, inodes, directories, etc.
•
The Log-structured File System (LFS) was designed in response to three trends in
technology: “smart” drives, disk bandwidth and main memory. LFS takes advantage of
these to increase FS performance:
- Disk bandwidth scaling significantly (40% a year), disk latency (performance) is not.
- “Smart” disks improve sequential access - sector # only, no C/H/S.
- Large main memories in machines:
• Large buffer caches, absorb large fraction of read requests
• Can use for writes as well, combine # of small writes into large writes
•
LFS collects writes in disk cache, write out entire collection in one large disk request
• Leverages disk bandwidth
• No seeks (assuming head is at end of log)
LFS Problems, Solutions
•
LFS has two challenges it must address for it to be practical:
1) Locating data written to the log.
- FFS places files in a location, LFS writes data “at the end”
2) Managing free space on the disk
- Disk is finite, so log is finite, cannot always append. LFS append-only quickly runs out
of disk space
- Need to recover deleted blocks in old parts of log
•
Approach:
- Fragment log into segments
- Thread segments on disk
- Segments can be anywhere
- Reclaim space by cleaning segments
- Read segment
- Copy live data to end of log
- Now have free segment you can reuse
•
Memory / disk cleaning is still a big problem
- Costly overhead [bracket processes]
Other File System Types
•
The first commercial UNIX FS was V6FS
•
The first FFS was FFS for BSD 4.2
•
The first journaled FS was JFS1 (IBM AIX). Other journaled file systems:
- jfs - Journaled File System - a filesystem contributed to Linux by IBM.
- xfs - A filesystem contributed to open source by SGI.
- reiserfs, developed by Namesys, default filesystem for SUSE Linux.
•
•
•
•
•
Some LINUX FS features:
Ext – The original native file system
Ext2 – FFS like filesystem using block group allocation instead of FFS extent allocation
Ext3 – Journaled version of Ext2
Ext4 – Extended version of Ext2 using extent, multiblock allocation, delayed allocation,
larger files sizes and checksumming for journal and INODE lists (“fast fsck”).
A fascinating comparison of OS Filesystems is kept here:
http://en.wikipedia.org/wiki/Comparison_of_file_systems
Virtual File Systems (VFS)
•
To support multitude of filesystems the operating system provides an abstraction called
VFS or the Virtual Filesystem.
•
Kernel level interface to all underlying file systems into one format – in memory.
•
VFS receives system calls from user program (open, write, stat, link, truncate, close)
•
Interacts with specific filesystem (support code) at mountpoint.
•
VFS translates between particular FS format (local disk FS, NFS) and VFS data in
memory.
•
Receives other kernel requests, usually for memory management.
•
Underlying filesystem is responsible for all physical filesystem management. User data,
directories, metadata.
LINUX RamDisk
•
A RAM disk is a filesystem in RAM (inverse concept of swap which is RAM on Disk).
RAM disks have fixed sizes and are treated like regular disk partitions.
•
Access time is much faster for a RAM disk than for a real, physical disk. RAM disks are
used to store temporary data in a high performance directory.
•
All RamDisk data is lost when the system is powered off and/or rebooted. Ramdisks are
useful for a number of things, like “Live CD” implementations (see Union FS).
•
Beginning with Linux kernel version 2.4 has built-in support for ramdisks. You can
check for RamDisk support by the commands:
dmesg | grep RAMDISK or ls –al /dev/ram*
•
You can increase initial RAMDISK size by adding ramdisk_size=16000 option on the
kernel entry of grub.conf. The RamDisk memory is permanently set aside once defined
(cannot be reclaimed by the kernel), so be careful of the size allocation for each
RAMDisk defined.
•
RamDisk devices always exist, but you must specifically define the filesystem and
mountpoint at every boot to access them. For example:
mke2fs -m 0 /dev/ram0
mkdir /mnt/rd0
mount /dev/ram0 /mnt/rd0
chown root /mnt/rd0
chmod 0750 /mnt/rd0
SWAP Space
•
Swap versus page – terminology.
•
RAM on Disk. Disk is 1 million times slower than RAM. RAM is cheap. So DON’T SWAP!!!!!
•
Ram utilization: top, vmstat, free
Show swap: swapon –s
In use: free –mt
•
Uses different area format – mkswap
•
Different and partition type: 82
•
Turn on swap area with swapon, off with swapoff. See manpage.
•
If low on virtual memory, can allocate temp swap space on an existing filesystem without reboot (see
lab). But this is even lower performance than regular swap.
•
Can combine swap on filesystem with RamDisk on solid state drives for almost as good as memory
performance. Why? Some OSes, software or hardware platforms have memory address limitations.
UnionFS:
File System Namespace Unification
•
UnionFS is an extension of VFS that involves merging the contents of two or more
directories/filesystems to present a unified view as a single mountpoint. NOT
DEVICES!!!
•
A union file system combines one (or more) R/O base directory(s) and a writable
overlay as R/W. Initially, the view contains the base filesystem as R/O. The overlay is
added second as R/W.
•
Any updates to the mountpoint are written to the overlay directory.
•
Uses: Live CD merge RAMDisk with CDROM (LINUX, KNOPPIX). Diskless NFS
clients, Server Consolidation. Examples: Sun TLS, BSD, MacOSx (from BSD), LINUX
– funionfs(FUSE), aufs (SourceForge).
•
UnionFS can be compiled into the kernel separately or installed with a separate product
– LINUX FUSE (Filesystem in User Space). Note the other options under FUSE.
•
When compiled natively into the kernel, unionfs shows up as a filesystem type under
mount:
mount –t unionfs -o dirs=/dir1=rw:/dir2=ro none /mountpoint
•
When installed separately in a product (funionfs under LINUX):
funionfs none –o dirs=/dir1=rw:/dir2=ro /mountpoint
LINUX Filesystem under User
Space (FUSE) Project
FUSE under VFS useable by ordinary users.
Commands: fusermount, funionfs, sshfs
Other mount options
•
mount –bind and mount –rbind can act as a “single directory” unionfs. That is you
can re-mount a portion of a file system at another mountpoint. This is not supported on
all UNIX versions. These can be made permanent in /etc/fstab.
•
Examples:
mount --bind olddir newdir
mount --rbind olddir newdir includes submounts
mount --move olddir newdir move a mountpoint.
•
Labeled mounts: you can mount a device by a label.
First label the device: e2label /dev/sda /home
Add to /etc/fstab: LABEL=/home /home ext3 defaults 1 2
Also uses: mount L+ option
•
See manpage for mount for other options.