<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="content-type"
content="text/html; charset=ISO-8859-1">
<title>Advanced Partition Formatting</title>
</head>
<body>
<span style="font-weight: bold;">22.4 </span><a
href="http://www.mythtv.org/docs/mythtv-HOWTO.html#toc22.4"
style="font-weight: bold;">Advanced Partition Formatting.</a><br>
<br>
The partitions that your distribution sets up for you may not be
optimized for large files. Using <a
href="http://www.mythtv.org/docs/mythtv-HOWTO-22.html#LVM">LVM</a> in
conjunction with the following techniques can be quite useful.<br>
<br>
Unlike a typical filesystem, a MythTV video partition is typically a
very large filesystem filled with a few, large files. Filesystem I/O is
usually not an issue, even in multi-tuner and/or multi-frontend setups.<br>
<br>
There is however, one aspect of filesystem performance that can have a
bearing on the performance of MythTV. In Linux, deleting a file
will pretty much tie up the hard drive until the deletion has been
completed. If deleting the file takes long enough, the video
capture buffer may overrun resulting in dropped frames. Some
filesystems are faster at deleting files than others and, for
multi-gigbyte MythTV video files, these differences can be significant.<br>
<br>
Fortunately, there are <a
href="http://aurora.zemris.fer.hr/filesystems/big.html">published tests</a>
that provide insight into filesystem performance under conditions
relevant to MythTV usage. In addition, some <a
href="http://www.gossamer-threads.com/perl/mailarc/gforum.cgi?post=106656;search_string=filesystem;guest=2417820&t=search_engine#106656">limited
testing</a> with very large files (10 gigabytes) was reported in the <a
href="http://www.gossamer-threads.com/archive/MythTV_C2/Users_F11/">MythTV
Users mailing list</a>.<br>
<br>
<span style="font-weight: bold;">Ext2</span><br>
<br>
<a href="http://e2fsprogs.sourceforge.net/ext2.html">Ext2</a> was the
defacto standard Linux filesystem for many years. It is stable,
provides good I/O performance, and fast file deletes. The one
disadvantage of Ext2 is that it is not a journaling filesystem and so a
file system consistency check (fsck), which is performed automatically
after a system crash, can take hours on a filesystem the size of a
typical MythTV partition.<br>
<br>
<span style="font-weight: bold;">Ext3</span><br>
<br>
<a
href="http://olstrans.sourceforge.net/release/OLS2000-ext3/OLS2000-ext3.html">Ext3</a>
is Ext2 with a journal, so your biggest gain is that in case of a crash
and reboot you won't have to wait very long for your partition to be
remounted.<br>
<br>
There are options available when formatting an Ext3 partition, as in:<br>
<code><br>
# mkfs.ext3 -T largefile4 -m 0 /dev/hdb1</code><br>
<br>
This example assumes that <code>/dev/hdb1</code> has already been
created using fdisk. If you're using LVM, <code>/dev/hdb1</code> may
be something like <code>/dev/VGforMyth/video</code>.<br>
<br>
The "<code>-m 0</code>" (zero, not "oh") parameter sets the amount of
spaced reserved for root to zero. By default, this is 5%, which on a
multi-gigabyte drive is a lot of reserved space.<br>
<br>
The "<code>-T largefile4</code>" option creates one inode per 4
megabytes, which can provide a few percent more storage space.
However, tests indicate that using the "<code>-T largefile4</code>"
option can drastically increase the amount of time required to delete a
large file and thus it should only be used with encoder settings that
produce small video files (YMMV).<br>
<br>
You may also modify some aspects of a filesystem such as the reserved
block percentage after it has been created using the tune2fs program:<br>
<br>
<code># tune2fs -m 0 /dev/hdb1</code><br>
<br>
You can check on your filesystem using the dumpe2fs program. See the
man page for details.<br>
<br>
<span style="font-weight: bold;">ReiserFS</span><br>
<br>
The <a href="http://www.namesys.com/">Reiser filesystem</a> is another
journaling filesystem commonly distributed with Linux. It is
known to be an extremely efficient filesystem and it especially excels
at managing partitions containing a large number of small files.
However, the tests indicate it is not the fastest at deleting very
large files. For that reason, it may not be the best choice when
using encoder bitrates that produce very large files.<br>
<br>
<span style="font-weight: bold;">JFS</span><br>
<br>
<a href="http://www-124.ibm.com/developerworks/oss/jfs/">JFS</a>
(Journaling File System) is a journaling filesystem originally
developed by IBM for AIX which was later released as open source.
It is not as pervasive as Ext3 or ReiserFS, however it is distributed
with RedHat 9 (RH9) and Fedora Core 1 (RHFC1), as well as other
distros. According to tests, JFS is the file deletion speed king,
deleting virtually any file in under one second, even files as large as
10 gigabytes.<br>
<br style="font-weight: bold;">
<span style="font-weight: bold;">XFS</span><br>
<br>
<a href="http://oss.sgi.com/projects/xfs/">XFS</a> is a journaling file
system originally developed by SGI for Irix, and later released as open
source. It is not distributed with RH9 or RHFC1, however it can
be easily installed via <a href="http://atrpms.physik.fu-berlin.de/">ATrpms</a>.
XFS provides deletion speeds for large files only slightly slower than
JFS. According to <a
href="http://aurora.zemris.fer.hr/filesystems/big.html">some tests</a>,
XFS appears to provide higher I/O rates than JFS, albeit at a higher
CPU loading. This last is probably only relevant for a
non-dedicated MythTV machine.
</body>
</html>