109
CHAPTER 5
Advanced File System
Management
Getting the Best Out of Your
File Systems
F
ile system management is among the first things that you do when you start using
Ubuntu Server. When you installed Ubuntu Server, you had to select a default file system.
At that time, you probably didn’t consider advanced file system options. If you didn’t, this
chapter will help you to configure those options. This chapter first provides an in- depth
look at the way a server file system is organized, so that you understand what tasks your
file system has to perform. This discussion also considers key concepts such as journaling
and indexing. Following that, you’ll learn how to tune and optimize the relevant Ubuntu
file systems.
Understanding File Systems
A file system is the structure that is used to access logical blocks on a storage device. For
Linux, different file systems are available, of which Ext2, Ext3, XFS, and, to some extent,
ReiserFS are the most important. All have in common the way in which they organize log-
ical blocks on the storage device. Another commonality is that inodes and directories play
a key role in allocating files on all four file systems. Despite these common elements, each
file system has some properties that distinguish it from the others. In this section you will
read both about the properties that all file systems have in common and about the most
important differences.
CHAPTER 5
N
ADVANCED FILE SYSTEM MANAGEMENT
110
Inodes and Directories
The basic building block of a file system is the logical block. This is a storage unit your
file system is using. Typically, it exists on a logical volume or a traditional partition (see
because you will need it in step 4 of this procedure.
3. Use the
`a^qcbo
command to access the file system on your device in debug mode.
For example, if your file system is
+`ar+o`]-
, you would use
`a^qcbo+`ar+o`]-
.
4. Use the
op]p
command that is available in the file system debugger to show the
contents of the inode. When done, use
atep
to close the
`a^qcbo
environment.
Listing 5-1. The Ext2/Ext3 debugfs Tool Allows You to Show the Contents of an Inode
nkkp<iah6+^kkp`a^qcbo+`ar+o`]-
`a^qcbo-*0,*4$-/)I]n).,,4%
`a^qcbo6op]p8-5:
Ejk`a6-5Pula6nacqh]nIk`a6,200Bh]co6,t,Cajan]pekj6.2/.04,,,,
Qoan6,Cnkql6,Oeva64.--513
Beha=?H6,@ena_pknu=?H6,
Hejgo6->hk_g_kqjp6-2-,2
Bn]ciajp6=``naoo6,Jqi^an6,Oeva6,
_peia6,t04-32.23))Pqa=ln.5-06,-6--.,,4
]peia6,t041a]/a5))OqjFqj..-16--6/3.,,4
ipeia6,t04-32.23))Pqa=ln.5-06,-6--.,,4
CHAPTER 5
$0-,4)0/2/%6.3/51).321,($EJ@%6.321-($0/20)02-5%6.321.).35,3($EJ@%6.35,4(
±
$02.,)0431%6.35,5).4-20($EJ@%6.4-21($0432)1-/-%6.4-22).40.-($EJ@%6.40..(
±
$1-/.)1/43%6.40./).4234($EJ@%6.4235($1/44)120/%6.424,).45/1($EJ@%6.45/2(
±
$1200)1455%6.45/3).5-5.($EJ@%6.5-5/($15,,)2-11%6.5-50).5005($EJ@%6.501,(
±
$2-12)20--%6.501-).53,2($EJ@%6.53,3($20-.)2223%6.53,4).552/($EJ@%6.5520(
±
$2224)25./%6.5521)/,..,($EJ@%6/,..-($25.0)3-35%6/,...)/,033($EJ@%6
If you look closely at the information that is displayed by using
`a^qcbo
, you’ll see that
it basically is the same information that is displayed when using
ho)h
on a given file. The
only difference is that in this output you can see the blocks that are in use by your file as
well, and that may come in handy when restoring a file that has been deleted by accident.
The interesting thing about the inode is that it contains no information about the
name of the file, because, from the perspective of the operating system, the name is not
important. Names are for human users and they can’t normally handle inodes too well.
To store names, Linux uses a directory tree.
A directory is a special kind of file, containing a list of files that are in the directory,
of Listing 5-1 with Listing 5-2. This is the inode for the same file after it has been copied
from the Ext2 volume to the Ext3 volume. As you can see, it has many fewer blocks to
manage.
Listing 5-2. A File System Supporting Extents Has Fewer Individual Blocks to Manage and
Thus Is Faster
nkkp<iah6+`a^qcbo+`ar+ouopai+nkkp
`a^qcbo-*0,*4$-/)I]n).,,4%
`a^qcbo6op]p8.014,:
Ejk`a6.014,Pula6nacqh]nIk`a6,200Bh]co6,t,Cajan]pekj6.,.2/01/-1
Qoan6,Cnkql6,Oeva64.--513
Beha=?H6,@ena_pknu=?H6,
Hejgo6->hk_g_kqjp6-2,20
Bn]ciajp6=``naoo6,Jqi^an6,Oeva6,
_peia6,t043./4aa))IkjFqh3--60,6/,.,,4
]peia6,t043./4aa))IkjFqh3--60,6/,.,,4
ipeia6,t043./4aa))IkjFqh3--60,6/,.,,4
>HK?GO6
$,)--%6-,2052)-,21,3($EJ@%6-,21,4($-.)-,/1%6-,21,5)-,31/.(
±
$@EJ@%6-,31//($EJ@%6-,31/0($-,/2).,,0%6-,31/1)-,41,/
PKP=H6.,,4
$AJ@%
A file system may use other techniques to work faster as well, such as allocation
groups. By using allocation groups, a file system divides the available space into chunks
and manages each chunk of disk space individually. By doing this, the file system can
achieve a much higher I/O performance. All Linux file systems use this technique; some
even use the allocation group to store backups of vital file system administration data.
Superblocks, Inode Bitmaps, and Block Bitmaps
To mount a file system, you need a file system superblock. Typically, this is the first block
>hk_g_kqjp6.2.-00,,
Naoanra`^hk_g_kqjp6-/-,3.,
Bnaa^hk_go6./412/03
Bnaaejk`ao62034023
Benop^hk_g6,
>hk_goeva60,52
Bn]ciajpoeva60,52
Naoanra`C@P^hk_go6-,-3
>hk_golancnkql6/.324
Bn]ciajpolancnkql6/.324
Without superblock, you cannot mount the file system; therefore, most file systems
keep backup superblocks at different locations in the file system. In that case, if the real
file system gets broken, you can mount using the backup superblock and still access the
file system anyway.
Apart from the superblocks, the file system contains an inode bitmap and a block
bitmap. By using these bitmaps, the file system driver can determine easily if a given
block or inode is available. When creating a file, the inode and blocks used by the file are
marked as in use, and when deleting a file, they are marked as available and thus can be
overwritten by new files.
After the inode and block bitmaps sits the inode table. This contains the administra-
tive information of all files on your file system. Since it normally is big (an inode is at least
128 bytes), there is no backup of the inode table.
CHAPTER 5
N
ADVANCED FILE SYSTEM MANAGEMENT
114
Journaling
With the exception of Ext2, all current Linux file systems support journaling. The journal
is used to track changes of files as well as metadata. The goal of using a journal is to make
sure that transactions are processed properly, especially if a power outage occurs. In that
^]nnean9jkja
.
Journaling offers three different journaling modes. All of these are specified as
options while mounting the file system, which allows you to use different journaling
modes on different file systems.
CHAPTER 5
N
ADVANCED FILE SYSTEM MANAGEMENT
115
s
`]p]9kn`ana`
: When using this option, only metadata is journaled and barriers
are enabled by default. This way, data is forced to be written to hard disk as fast as
possible, which reduces the chances of things going wrong. This journaling mode
uses the optimal balance between performance and data security.
s
`]p]9snepa^]_g
: If you want the best possible performance, use this option. This
option only journals metadata, but does not guarantee data integrity. This means
that, based on the information in the journal, when your server crashes, the file
system can try to repair the data but may fail, in which case you will end up with
the old data (dating from before the moment that you initialized the write action)
after a system crash. This option at least guarantees fast recovery after a system
crash, which is sufficient for many environments.
s
`]p]9fkqnj]h
: If you want the best guarantees for your data, use this option. When
using this option, data and metadata is journaled. This ensures the best data integ-
rity, but gives bad performance because all data has to be written twice. It has to
be written to the journal first, and then to the disk when it is committed to disk. If
dynamic file system with lots of tuning options that make it an excellent candidate for
handling large amounts of data. ReiserFS should be avoided. Its main developer, Hans
Reiser, is in prison for second- degree murder, so the future of ReiserFS is currently very
uncertain. Regardless, it is covered later in the chapter just in case you are stuck using
a ReiserFS file system.
Optimizing Ext2/Ext3
Before the arrival of journaling file systems, Ext2 was the default file system on all Linux
distributions. It was released in 1993 as a successor to the old and somewhat buggy Ext
file system. Ext2 was successful for a few years, until the release of Ext3 in the late 1990s.
Initially, there was only one difference between Ext2 and Ext3: Ext3 has a journal, whereas
Ext2 doesn’t have one. Over time, patches have enhanced Ext3 some more. For instance,
Ext3 has directory indexing and works with extents, neither of which is the case for Ext2.
The successor of Ext3 is Ext4. This file system is already well on its way toward release, but
because it is not included in Ubuntu Server 8.04, I won’t cover it in this book.
On a current Linux server, it isn’t really a dilemma whether you should use Ext2 or
Ext3. In almost all cases you want to use Ext3, because it has more features. Choose Ext2
only if you specifically don’t want a journal, perhaps because your file system is too small
to host a journal. For example, this is the case for the
+^kkp
file system. Because Ext2 and
Ext3 are almost completely compatible, I’ll cover Ext3 optimization in the rest of this
subsection.
Creating Ext2/Ext3
While creating an Ext3 file system, you can pass many options to it. Even if you don’t pass
any options, some options will be applied automatically from the
+ap_+iga.bo*_kjb
con-
figuration file. In this file, you can include default options for Ext2 and Ext3. Listing 5-4
shows you what the contents of this file look like.
Copyright: Tài liệu đại học ©