[gentoo-doc-cvs] cvs commit: afig-ct-ext3-intro.xml

public inbox for gentoo-doc-cvs@lists.gentoo.org
 help / color / mirror / Atom feed

From: "Xavier Neys" <neysx@lark.gentoo.org>
To: gentoo-doc-cvs@lists.gentoo.org
Subject: [gentoo-doc-cvs] cvs commit: afig-ct-ext3-intro.xml
Date: Sun, 21 Aug 2005 22:23:44 +0000	[thread overview]
Message-ID: <200508212223.j7LMNA5v001078@robin.gentoo.org> (raw)

neysx       05/08/21 22:23:44

  Added:       xml/htdocs/doc/en/articles afig-ct-ext3-intro.xml
                        prompt-magic.xml
  Log:
  #103211 & #101920, GuideXMLified articles

Revision  Changes    Path
1.1                  xml/htdocs/doc/en/articles/afig-ct-ext3-intro.xml

file : http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/doc/en/articles/afig-ct-ext3-intro.xml?rev=1.1&content-type=text/x-cvsweb-markup&cvsroot=gentoo
plain: http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/doc/en/articles/afig-ct-ext3-intro.xml?rev=1.1&content-type=text/plain&cvsroot=gentoo

Index: afig-ct-ext3-intro.xml
===================================================================
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">

<guide link="/doc/en/articles/afig-p7.xml">

<title>Advanced Filesystem Implementor's Guide : Introducing ext3</title>

<author title="Author">
  <mail link="drobbins@gentoo.org">Daniel Robbins</mail>
</author>
<author title="Editor">
<mail link=" dhaskew@earthlink.net">David H. Askew</mail>
</author>

<abstract>
With the 2.4 release of Linux come a host of new filesystem possibilities,
including Reiserfs, XFS, GFS, and others. These filesystems sound cool, but
what exactly can they do, what are they good at, and exactly how do you go
about safely using them in a production Linux environment? Daniel Robbins
answers these questions by showing you how to set up these new advanced
filesystems under Linux 2.4. In this installment, Daniel takes a look at ext3,
a new improved version of ext2 with journaling capabilities.
</abstract>

<version>1.0</version>
<date>2005-08-13</date>

<chapter>
<title>Introduction</title>
<section>
<body>

<note>
The original version of this article was first published on IBM developerWorks,
and is property of Westtech Information Services. This document is an updated
version of the original article, and contains various improvements made by the
Gentoo Linux Documentation team.
</note>

<p>
In the past few installments, we've taken a bit of a detour by looking at
non-traditional filesystems such as tmpfs and devfs. Now, it's time to get back
to disk-based filesystems, and we do this by taking a look at ext3. The ext3
filesystem, designed by Dr. Stephen Tweedie, is built on the framework of the
existing ext2 filesystem; in fact, ext3 is very similar to ext2 except for one
small (but important) difference -- it supports journaling. Yet even with this
small addition, I think you'll find that that ext3 has several surprising and
intriguing capabilities.  In this article, I'll give you a good understanding
of how ext3 compares to the other journaling filesystems currently available.
In my next article, we'll get ext3 up and running.
</p>

</body>
</section>
</chapter>

<chapter>
<title>Understanding Ext3</title>
<section>
<body>

<p>
So, how does ext3 compare to ReiserFS? In previous articles, I explained how
ReiserFS is well suited to handling small files (under 4K), and in certain
situations, ReiserFS' small file performance is ten to fifteen times greater
than that of ext2 and ext3. However, while ReiserFS has many strengths, it also
has weaknesses. In the current implementation of ReiserFS (version 3.6),
certain file access patterns can actually result in significantly worse
performance than ext2 and ext3, particularly when reading large mail
directories. Also, ReiserFS doesn't have a good track record of NFS
compatibility and has poor sparse file performance. In contrast, ext3 is a very
well-rounded filesystem. It's a lot like ext2; it's not going to give you the
blazingly fast small-file performance that ReiserFS gives you, but it's not
going to give you any unexpected performance or functionality hiccups either.
</p>

<p>
One of the nice things about ext3 is that because it is based on the ext2 code,
ext2 and ext3's on-disk format is identical; this means that a cleanly
unmounted ext3 filesystem can be remounted as an ext2 filesystem with
absolutely no problems. And that's not all. Thanks to the fact that ext2 and
ext3 use identical metadata, it's possible to perform in-place ext2 to ext3
filesystem upgrades. Yes, you read that right. By upgrading a few key system
utilities, installing a modern 2.4 kernel and typing in a single tune2fs
command per filesystem, you can convert your existing ext2 servers into
journaling ext3 systems. You can even do this while your ext2 filesystems are
mounted. The transition is safe, reversible, and incredibly easy, and unlike a
conversion to XFS, JFS, or ReiserFS, you don't need to back up and recreate
your filesystems from scratch. Now, for a moment, consider the thousands of
production ext2 servers in existence that are just minutes away from an ext3
upgrade; then, you'll have a good grasp of ext3's importance to the Linux
community.
</p>

<p>
If I had to describe ext3 in one word, I'd call it "comfortable". It's
incredibly easy to ext3-enable an existing ext2 system, and after you do,
you're not going to run into any unexpected performance quirks. And there's yet
another way that ext3 excels in the comfort department; ext3 happens to be one
of the most reliable journaled filesystems available for Linux, as I explain
below. 
</p>

</body>
</section>
</chapter>

<chapter>
<title>Ext3 reliability</title>

<section>
<body>

<p>
In addition to being ext2-compatible, ext3 inherits other benefits by sharing
ext2's metadata format. For one, ext3 users gain access to a rock-solid fsck
tool. You'll recall that one of the points of using a journaling filesystem is
to avoid the need for an exhaustive fsck in the first place; however if you do
end up getting corrupt metadata, either from a flaky kernel, bad hard drive, or
something else, you'll greatly appreciate the fact that ext3 inherits ext2's
fsck. In contrast, ReiserFS' fsck is in its infancy, and fixing flaky metadata
when it does show up can be a difficult and dangerous process. 
</p>

</body>
</section>

<section>
<title>Metadata-only journaling</title>
<body>

<p>
Interestingly, ext3 handles journaling very differently than ReiserFS and other
journaling filesystems do. With ReiserFS, XFS, and JFS, the filesystem driver
journals metadata, but makes no provisions for journaling data. With
metadata-only journaling, your filesystem metadata is going to be rock solid,
and you will probably never need to perform an exhaustive fsck. However,
unexpected reboots and system lock-ups can result in significant corruption of
recently-modified data. Ext3 uses a couple of innovative solutions to avoid
these problems, which we'll look at in a bit.
</p>

<p>
But first, it's important to understand exactly how metadata-only journaling
could end up biting you. As an example, let's say that you were modifying a
file called /tmp/myfile.txt when the machine unexpectedly locked up, forcing a
reboot. If you were using a metadata-only journaling filesystem such as
ReiserFS, XFS or JFS, your filesystem metadata would be easily repaired, thanks
to the metadata journal, and you wouldn't need to sit through a laborious fsck.
</p>

<p>
However, there's the distinct possibility that when you load /tmp/myfile.txt
into a text editor, your file will not simply be missing recent changes, but
will contain a good amount of garbage and may even be completely unreadable.
This isn't something that will always happen, but it could happen and often
does.
</p>

<p>
Here's why. Typical journaled filesystems like ReiserFS, XFS, and JFS take
extra special care of metadata, but don't pay too much attention to data. In
our above example, the filesystem driver was in the process of modifying
several filesystem blocks. The filesystem driver updated the appropriate
metadata, but didn't have time to flush the data from its caches to the new
blocks on disk. Thus, when you loaded up /tmp/myfile.txt into a text editor,
part or all of the file contained garbage -- blocks of data that didn't get
initialized in time before the system locked up.
</p>

</body>
</section>

</chapter>

<chapter>
<title>The ext3 approach</title>
<section>
<body>

<p>
Now that we have a good general understanding of this problem, let's look how
ext3 implements journaling. In ext3, the journaling code uses a special API
called the Journaling Block Device layer, or JBD. The JBD has been designed for
the express purpose of implementing a journal on any kind of block device.
Ext3 implements its journaling by "hooking in" to the JBD API. For example, the
ext3 filesystem code will inform the JBD of modifications it is performing, and
will also request permission from the JBD before modifying certain data on
disk. By doing so, the JBD is given the appropriate opportunities to manage the
journal on behalf of the ext3 filesystem driver.  It's quite a nice
arrangement, and because the JBD is being developed as a separate, generic
entity, it could be used to add journaling capabilities to other filesystems in
the future.
</p>

1.1                  xml/htdocs/doc/en/articles/prompt-magic.xml

file : http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/doc/en/articles/prompt-magic.xml?rev=1.1&content-type=text/x-cvsweb-markup&cvsroot=gentoo
plain: http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/doc/en/articles/prompt-magic.xml?rev=1.1&content-type=text/plain&cvsroot=gentoo

Index: prompt-magic.xml
===================================================================
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/doc/en/articles/prompt-magic.xml,v 1.1 2005/08/21 22:23:44 neysx Exp $ -->

<guide link="/doc/en/articles/prompt-magic.xml" lang="en">

<title>Prompt magic</title>

<author title="Author">
  <mail link="drobbins@gentoo.org">Daniel Robbins</mail>
</author>
<author title="Editor">
  <mail link="jackdark@gmail.com">Joshua Saddler</mail>
</author>

<abstract>
Why stick with the standard boring shell prompt when you can easily make it
colorful and more informative? In this tip, Daniel Robbins will show you how to
get your shell prompt just the way you like it, as well as how to dynamically
update your X terminal's title bar.
</abstract>

<version>1.0</version>
<date>2005-08-21</date>

<chapter>
<title>Enhancing the system prompt</title>
<section>
<body>

<note>
The original version of this article was first published on IBM developerWorks,
and is property of Westtech Information Services. This document is an updated
version of the original article, and contains various improvements made by the
Gentoo Linux Documentation team.
</note>

<p>
As Linux/UNIX people, we spend a lot of time working in the shell, and in many
cases, this is what we have staring back at us:
</p>

<pre caption="The normal user prompt">
bash-2.04$
</pre>

<p>
If you happen to be root, you're entitled to the "prestige" version of this
beautiful prompt:
</p>

<pre caption="The root prompt">
bash-2.04#
</pre>

<p>
These prompts are not exactly pretty. It's no wonder that several Linux
distributions have upgraded their default prompts that add color and additional
information to boot. However, even if you happen to have a modern distribution
that comes with a nice, colorful prompt, it may not be perfect. Maybe you'd
like to add or change some colors, or add (or remove) information from the
prompt itself. It isn't hard to design your own colorized, tricked-out prompt
from scratch.
</p>

</body>
</section>
<section>
<title>Prompt basics</title>
<body>

<p>
Under bash, you can set your prompt by changing the value of the <c>PS1</c>
environment variable, as follows:
</p>

<pre caption="Altering the environment variable">
$ <i>export PS1="> "</i>
>
</pre>

<p>
Changes take effect immediately, and can be made permanent by placing the
<c>export</c> definition in your <path>~/.bashrc</path> file. <c>PS1</c> can
contain any amount of plain text that you'd like:
</p>

<pre caption="A custom prompt">
$ <i>export PS1="This is my super prompt > "</i>
This is my super prompt >
</pre>

<p>
While this is, um, interesting, it's not exactly useful to have a prompt that
contains lots of static text. Most custom prompts contain information like the
current username, working directory, or hostname.  These tidbits of information
can help you to navigate in your shell universe. For example, the following
prompt will display your username and hostname:
</p>

<pre caption="A more useful prompt">
$ <i>export PS1="\u@\H > "</i>
drobbins@freebox >
</pre>

<p>
This prompt is especially handy for people who log in to various machines under
various differently-named accounts, since it acts as a reminder of what machine
you're actually on and what privileges you currently have.
</p>

<p>
In the above example, we told bash to insert the username and hostname into the
prompt by using special backslash-escaped character sequences that bash
replaces with specific values when they appear in the <c>PS1</c> variable. We
used the sequences <c>\u</c> (for username) and <c>\H</c> (for the first part
of the hostname). Here's a complete list of all special sequences that bash
recognizes (you can find this list in the bash man page, in the "PROMPTING"
section):
</p>

<table>
<tr>
  <th>Sequence</th>
  <th>Description</th>
</tr>
<tr>
  <ti>\a</ti>
  <ti>The ASCII bell character (you can also type <c>\007</c>)</ti>
</tr>
<tr>
  <ti>\d</ti>
  <ti>Date in "Wed Sep 06" format</ti>
</tr>
<tr>
  <ti>\e</ti>	
  <ti>ASCII escape character (you can also type <c>\033</c>)</ti>
</tr>
<tr>
  <ti>\h</ti>
  <ti>First part of hostname (such as "mybox")</ti>
</tr>
<tr>
  <ti>\H</ti>
  <ti>Full hostname (such as "mybox.mydomain.com")</ti>
</tr>
<tr>
  <ti>\j</ti>
  <ti>
    The number of processes you've suspended in this shell by hitting <c>^Z</c>
  </ti>
</tr>
<tr>
  <ti>\l</ti>
  <ti>The name of the shell's terminal device (such as "ttyp4")</ti>
</tr>
<tr>
  <ti>\n</ti>
  <ti>Newline</ti>
</tr>
<tr>
  <ti>\r</ti>
  <ti>Carriage return</ti>
</tr>
<tr>
  <ti>\s</ti>
  <ti>The name of the shell executable (such as "bash")</ti>
</tr>
<tr>
  <ti>\t</ti>
  <ti>Time in 24-hour format (such as "23:01:01")</ti>
</tr>
<tr>
  <ti>\T</ti>
  <ti>Time in 12-hour format (such as "11:01:01")</ti>
</tr>
<tr>
  <ti>\@</ti>
  <ti>Time in 12-hour format with am/pm</ti>
</tr>
<tr>
  <ti>\u</ti>
  <ti>Your username</ti>
</tr>
<tr>
  <ti>\v</ti>
  <ti>Version of bash (such as 2.04)</ti>
</tr>
<tr>
  <ti>\V</ti>
  <ti>Bash version, including patchlevel</ti>
</tr>
<tr>
  <ti>\w</ti>

-- 
gentoo-doc-cvs@gentoo.org mailing list

next             reply	other threads:[~2005-08-21 22:23 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-08-21 22:23 Xavier Neys [this message]
  -- strict thread matches above, loose matches on Subject: below --
2005-08-21 22:29 [gentoo-doc-cvs] cvs commit: afig-ct-ext3-intro.xml Xavier Neys
2005-10-09 17:13 Lukasz Damentko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200508212223.j7LMNA5v001078@robin.gentoo.org \
    --to=neysx@lark.gentoo.org \
    --cc=docs-team@lists.gentoo.org \
    --cc=gentoo-doc-cvs@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Be sure your reply has a Subject: header at the top and a blank line before the message body.

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox