Difference between pages "Funtoo Filesystem Guide, Part 5" and "Template:Subarch"

From Funtoo
(Difference between pages)
Jump to navigation Jump to search
 
 
Line 1: Line 1:
{{Article
<includeonly>{{#widget:AddThis}}{{#if:{{{title|}}}|
|Author=Drobbins
{{DISPLAYTITLE:Download - {{{title}}}}}
|Previous in Series=Funtoo Filesystem Guide, Part 4
|
|Next in Series=Funtoo Filesystem Guide, Part 6
{{DISPLAYTITLE:Download - {{{subarch}}}}}
}}'''This page lists CPU-optimized builds of Funtoo Linux for {{#if:{{{title|}}}|{{{title}}} ({{{subarch}}} subarch)|{{{subarch}}}}} [[{{{CPU Family}}}]].'''
 
{{{Description|}}}
{{#seo:
|title={{#if:{{{title|}}}|Download - {{{title}}}|Download - {{{subarch}}}}}
|keywords=funtoo,linux,build,subarch,{{{subarch}}},{{{title}}}
|description=his page describes a CPU-optimized build of Funtoo Linux for {{#if:{{{title|}}}|{{{title}}} ({{{subarch}}} subarch)|{{{subarch}}}}} [[{{{CPU Family}}}]].
}}
}}
== Introduction ==
{{#set:CPU Family={{{CPU Family|}}}|subarch={{{subarch|}}}|CHOST={{{CHOST|}}}|CFLAGS={{{CFLAGS|}}}|USE={{{USE|}}}|CPU Features={{{CPU Features|}}}|Description={{{Description|}}}|title={{{title|}}}}}
 
=== Optimizations ===
Back around 2002, when this article was originally written, Andrew Morton had a
__NOTOC__
nice little introduction to using ext3 on his Web site. His site has since
{{TableStart}}
disappeared, so in this updated article, I'll summarize Andrew Morton's
<tr><td>CHOST</td><td><code>{{{CHOST|}}}</code></td></tr>
original documentation. Then, in the second half of the article, we'll delve
<tr><td>CFLAGS</td><td><code>{{{CFLAGS|}}}</code></td></tr>
into some meatier ext3 topics, ones that I think you'll find very useful.
<tr><td>USE</td><td>{{#if:{{{USE|}}}|<code>{{{USE}}}</code>|(none)}}</td></tr>
 
{{TableEnd}}{{#vardefine:subarch|{{{subarch|}}}}}{{#get_web_data:url=http://build.funtoo.org/index.xml|format=xml|use xpath|data=builds=/subarches/subarch[@name='{{{subarch|}}}']/@builds}}{{#vardefine:builds|{{#external_value:builds}}}}
== Ext3 QuickStart ==
=== Download ===
 
{{#if:{{#var:builds}}|This section lists the Funtoo Linux builds currently available for download for '''{{{subarch}}}'''. A full list of Funtoo Linux builds can be found on the [[Subarches]] page.
=== (Not) Patching the Kernel ===
{{table|1=
 
<tr><th class="active">Build</th><th class="active">Variant</th><th class="active">Latest Build</th><th class="active">Download</th><th class="active">Browse Mirror</th></tr>{{#arraymaptemplate:{{#var:builds}}|DisplayBuilds|,|}}}}|No downloadable stage builds are currently available for this sub-architecture.}}
These days, there is no need to patch your kernel for ext3. Ext3 has been
[[Category:Subarches]]
incorporated into the Linux kernel for a long time, and is very mature.
__NOEDITSECTION__
 
=== Detailed Description ===
=== Converting ext2 to ext3 ===
</includeonly>
 
One of the nice things about ext3 is that you can easily convert an ext2
filesystem to be an ext3 filesystem. All that you need to do is to create a
journal on the ext2 filesystem, as follows:
 
<pre>tune2fs -j /dev/sdXX</pre>
 
You can even do this while the filesystem is mounted. If it ''is'' currently
mounted, it will not function as an ext3 filesystem until you are able to
remount it as ext3. Remember to update <tt>/etc/fstab</tt> to so that it refers
to the new filesystem as an <tt>ext3</tt> filesystem.
 
=== Creating New Ext3 Filesystems ===
 
Simply use the <tt>-j</tt> option with <tt>mke2fs</tt>, as follows:
 
<pre>mke2fs -j /dev/sdXX</pre>
 
=== Switching Between Ext2 and Ext3 ===
 
It is possible to mount an ext3 filesystem as an ext2 filesystem, as long as
the ext3 filesystem has been cleanly unmounted. Simply specify a filesystem
type of <tt>ext2</tt> when mounting an ext3 filesystem with older kernels. You
can also specify a filesystem type of <tt>auto</tt> in <tt>/etc/fstab</tt>,
which will tell the <tt>mount</tt> and <tt>fsck</tt> commands to utilize the
filesystem as ext3 if such support is available, otherwise falling back to
ext2.
 
=== Fixing Dirty Ext3 Filesystems ===
 
If your ext3 filesystem was not cleanly unmounted, then you should be able clean it up using <tt>e2fsck</tt> as follows:
 
<pre>e2fsck -fy /dev/sdXX</pre>
The filesystem should now be mountable as ext2.
 
=== Ext3 Root Filesystem Tricks ===
 
If you want to force a Linux kernel to mount an ext3 filesystem as an ext2
filesystem, add the <tt>rootfstype=ext2</tt> kernel boot parameter to the
kernel boot parameters in <tt>lilo.conf</tt> or <tt>grub.conf</tt>.
 
To tell the Linux kernel to mount your root ext3 filesystem using a particular
journaling mode, use the <tt>rootflags</tt> kernel boot parameter as follows
(using a <tt>grub.conf</tt> example):
 
<pre>kernel /boot/bzImage rootflags=data=journal root=/dev/sda3</pre>
 
=== Filesystem Check Intervals ===
 
By default, <tt>e2fsck</tt> will perform an exhaustive filesystem check every
now and then, even if the filesystem was cleanly unmounted. By default, this
happens every twentieth mount or every 180 days, whichever comes first.
 
While this might have been handy for ext2 filesystems, it's not optimal for
ext3. To turn this automatic exhaustive filesystem check off, use the following
<tt>tune2fs</tt> command:
 
<pre>tune2fs -i 0 -c 0 /dev/sdXX</pre>
 
You can view the filesystem check interval (as well as lots of other
interesting information) by typing <tt>tune2fs -l /dev/sdXX</tt>.
 
=== External Journals ===
 
Ext3 supports the ability to place the journal on a separate persistent device. To create an external journal on <tt>/dev/sdb</tt>, type:
 
<pre>mke2fs -O journal_dev /dev/sdb</pre>
Then, to create an ext3 filesystem on <tt>/dev/sda3</tt> that uses this external journal, type:
 
<pre>mke2fs -J device=/dev/sdb /dev/sda3
mount /dev/sda3 /mnt/test -t ext3</pre>
== Ext3 Journaling Options and Write Latency ==
 
Ext3 allows you to choose from one of three data journaling modes at filesystem
mount time: <tt>data=writeback</tt>, <tt>data=ordered</tt>, and
<tt>data=journal</tt>.
 
To specify a journal mode, you can add the appropriate string
(<tt>data=journal</tt>, for example) to the options section of your
<tt>/etc/fstab</tt>, or specify the <tt>-o data=journal</tt> command-line
option when calling mount directly.
 
As we covered earlier in this article, if you'd like to specify the data
journaling method used for your root filesystem (<tt>data=ordered</tt> is the
default), you can to use a special kernel boot option called
<tt>rootflags</tt>. So, if you'd like to put your root filesystem into full
data journaling mode, add <tt>rootflags=data=journal</tt> to your kernel boot
options.
 
=== <tt>data=writeback</tt> Mode ===
 
In <tt>data=writeback mode</tt>, ext3 doesn't do any form of data journaling at
all, providing you with similar journaling found in the XFS, JFS, and ReiserFS
filesystems -- metadata only. As I explained in my
[http://www.funtoo.org/en/articles/linux/ffg/4/ previous article], this could
allow recently modified files to become corrupted in the event of an unexpected
reboot. Despite this drawback, <tt>data=writeback</tt> mode should give you the
best ext3 performance under most conditions.
 
=== <tt>data=ordered</tt> Mode ===
 
In <tt>data=ordered</tt> mode, ext3 only officially journals metadata, but it logically groups metadata and data blocks into a single unit called atransaction. When it's time to write the new metadata out to disk, the associated data blocks are written first. <tt>data=ordered</tt> mode
effectively solves the corruption problem found in <tt>data=writeback</tt> mode and most other journaled filesystems, and it does so without requiring fulldata journaling. In general, <tt>data=ordered</tt> ext3 filesystems performslightly slower than <tt>data=writeback</tt> filesystems, but significantly faster than their full data journaling counterparts.When appending data to files, <tt>data=ordered</tt> mode provides all of the integrity guarantees offered by ext3's full data journaling mode. However, ifpart of a file is being overwritten and the system crashes, it's possible that
the region being written will contain a combination of original blocks
interspersed with updated blocks. This is because <tt>data=ordered</tt>
provides no guarantees as to which blocks are overwritten first, so you can't
assume that just because overwritten block x was updated, that overwrittenblock x-1 was updated as well. Instead, <tt>data=ordered</tt> leaves the writeordering up to the hard drive's write cache. In general, this limitation
doesn't end up negatively impacting people very often, since file appends are
generally much more common than file overwrites. For this reason,<tt>data=ordered</tt> mode is a good higher-performance replacement for fulldata journaling.
 
=== <tt>data=journal</tt> Mode ===
 
<tt>data=journal</tt> mode provides full data and metadata journaling. All new
data is written to the journal first, and then to its final location. In the
event of a crash, the journal can be replayed, bringing both data and metadata
into a consistent state.
 
Theoretically, <tt>data=journal</tt> mode is the slowest journaling mode of all, since data gets written to disk twice rather than once. However, it turns
out that in certain situations, <tt>data=journal</tt> mode can be blazingly
fast. Andrew Morton, after hearing reports on LKML that ext3
<tt>data=journal</tt> filesystems were giving people unbelievably greatinteractive filesystem performance, decided to put together a little test.
First, he created simple shell script designed to write data to a test
filesystem as quickly as possible:
 
<pre>while true
do       
    dd if=/dev/zero of=largefile bs=16384 count=131072
done</pre>
While data was being written to the test filesystem, he attempted to read 16MB of data from another ext2 filesystem on the same disk, timing the results:
 
<pre># time cat 16-meg-file &gt; /dev/null</pre>
 
The results were astounding. <tt>data=journal</tt> mode allowed the 16 MB file to be read from 9 to over 13 times faster than other ext3 modes, ReiserFS, and even ext2 (which has no journaling overhead):
 
{| {{Table}}
!Filesystem||16 MB read time (seconds)
|-
|ext2
|78
|-
|ReiserFS
|67
|-
|ext3 data=ordered
|93
|-
|ext3 data=writeback
|74
|-
|ext3 data=journal
|7
|}
 
Andrew repeated this test, but tried to read a 16 MB file from the test filesystem (rather than a different filesystem), and he got identical results. So, what does this mean? Somehow, ext3's <tt>data=journal</tt> mode is incredibly well-suited to situations where data needs to be read from and written to disk at the same time. Therefore, ext3's <tt>data=journal</tt> mode, which was assumed to be the slowest of all ext3 modes in nearly all conditions, actually turns out to have a major performance advantage in busy environments where interactive IO performance needs to be maximized. Maybe <tt>data=journal</tt> mode isn't so sluggish after all!
 
Andrew is still trying to figure out exactly why data=journal mode is doing so much better than everything else. When he does, he may be able to add the necessary tweaks to the rest of ext3 so that data=writeback and data=ordered modes see some benefit as well.
 
I hope to see you soon when I release the next installment in the Funtoo Filesystem Guide!
 
== Resources ==
Be sure to checkout the other articles in this series:
* [[Funtoo Filesystem Guide, Part 1|Part 1]]: Journaling and ReiserFS
* [[Funtoo Filesystem Guide, Part 2|Part 2]]: Using ReiserFS and Linux
* [[Funtoo Filesystem Guide, Part 3|Part 3]]: Tmpfs and bind mounts
* [[Funtoo Filesystem Guide, Part 4|Part 4]]: Introducing Ext3
* [[Funtoo Filesystem Guide, Part 5|Part 5]]: Ext3 in action
 
[[Category:Filesystem Guides]]
[[Category:Articles]]
{{ArticleFooter}}

Revision as of 08:01, January 6, 2015

Retrieved from "https://www.funtoo.org/index.php?title=Funtoo_Filesystem_Guide,_Part_5&oldid=8376"