[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: partman recipes and noatime?



Hi,

On Sun, Feb 20, 2005 at 05:56:49PM +0000, W. Borgert wrote:
> On Tue, Feb 15, 2005 at 04:12:42PM +0200, Anton Zinoviev wrote:
...
> > 	options/noatime { noatime - do not update inode access times at each access }
...
> Hm, I tried this, but it didn't work - neither for ext3 nor
> xfs.  Are you sure about the syntax?

I should have RTFM: "before (the curly bracket) must be no
space."  Now it works.  As I like to have option handling
in the documentation, I attach "partman-auto Recipe Files"
with noatime stuff added.  I hacked this in DocBook/XML
format in the hope that it can be used for the installer
manual.

Cheers,
-- 
W. Borgert <debacle@debian.org>, http://people.debian.org/~debacle/
<?xml version='1.0' encoding='ISO-8859-1'?>
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd";>
<article lang="en">
  <title>partman-auto Recipe Files</title>

  <section>
    <title>Introduction</title>

    <para>partman-auto is the part of the partitioner that
    automatically partitions disks.  It is controlled by recipes,
    which are provided in partman-auto as files, but may also be
    provided by other udebs, or by preseeding.  This document explains
    the format of the recipes and how to use them.</para>
  </section>

  <section>
    <title>Format Of The Recipes</title>

    <para>All new lines and tabs in the recipe are converted to
    spaces.  Then two or more consecutive spaces are converted to one
    space.  Almost all tokens must be separated by spaces.  An
    important exception is the opening curly bracket
    (<literal>{</literal>); before it there must be
    <emphasis>no</emphasis> space.</para>

    <para>In the following rules we denote spaces by
    <literal>_</literal>.</para>

    <programlisting>&lt;recipe&gt;::=&lt;header&gt;_&lt;partitions&gt;

&lt;header&gt;::=&lt;simple name&gt;|&lt;debconf name&gt;

&lt;simple name&gt;::=&lt;name&gt;_:

&lt;name&gt; can be for example "Multi user system".

&lt;debconf name&gt;::=&lt;debconf template&gt;_::</programlisting>

    <para>The purpose of <literal>debconf name</literal> is to allow
    translation of the names of the recipes into different
    languages.</para>

    <programlisting>&lt;partitions&gt;::=&lt;partition&gt;|&lt;partition&gt;_&lt;partitions&gt;

&lt;partition&gt;::=&lt;limits&gt;_&lt;specifiers&gt;_.

&lt;limits&gt;::=&lt;minimal size&gt;_&lt;priority&gt;_&lt;maximal size&gt;_&lt;parted fs&gt;</programlisting>

    <para><literal>minimal size</literal> is the minimal allowed size
    of the partition in megabytes.  It is rounded to cylinder size, so
    if you make <literal>minimal size</literal> to be 20 MB and the
    cylinder size is 12MB, then it is possible for the partition to be
    only 12MB.  These sizes may also be given as a percentage, which
    makes the size be that percentage of the system's total
    RAM.</para>

    <para><literal>maximal size</literal> is the maximal size for the
    partition, i.e. a limit size such that there is no sense to make
    this partition larger.</para>

    <para><literal>priority</literal> is some size usually between
    <literal>minimal size</literal> and <literal>maximal
    size</literal>.  It determines the priority of this partition in
    the contest with the other partitions for size.  Notice that if
    <literal>priority</literal> is too small (relative to the priority
    of the other partitions) then this partition will have size close
    to <literal>minimal size</literal>.  That's why it is recommended
    to give small partitions a <literal>priority</literal> larger than
    their <literal>maximal size</literal>.</para>

    <para><literal>parted fs</literal> is the file system as known to
    parted of this partition.</para>

    <programlisting>&lt;specifiers&gt;::=&lt;specifier&gt;|&lt;specifier&gt;_&lt;specifiers&gt;

&lt;specifier&gt;::=&lt;internal specifier&gt;|&lt;regular specifier&gt;

&lt;internal specifier&gt;::=$primary{_}|$bootable{_}</programlisting>

    <para><literal>$primary{_}</literal> says that the partition
    should be primary (if possible).  <literal>$bootable{_}</literal>
    says that the bootable flag will be set.</para>

    <programlisting>&lt;regular specifier&gt;::=&lt;file name&gt;{ &lt;file contents&gt; }</programlisting>

    <para><literal>file name</literal> is a file to be created in the
    directory of the partition in partman's filesystem info. (See
    section 2.4 of the partman manual for details.)  <literal>file
    contents</literal> is the information to write in this
    file.</para>
  </section>

  <section>
    <title>Examples</title>

    <para>Here is a very simple recipe that creates a swap partition
    and uses the rest of the disk for one large root
    filesystem.</para>

    <programlisting>partman-auto/text/atomic_scheme ::

500 10000 1000000 ext3
        $primary{ }
        $bootable{ }
        method{ format }
        format{ }
        use_filesystem{ }
        filesystem{ ext3 }
        mountpoint{ / } .

64 512 300% linux-swap
        method{ swap }
        format{ } .</programlisting>

    <para>Here the root partition must be at least 500 mb, and has
    effectively no maximum size. The swap partition ranges from 64 mb
    to 3 times the system&apos;s ram.</para>

    <para>Note the use of <literal>$bootable{ }</literal> to make the
    partition bootable, and <literal>$primary{ }</literal> to mark it
    as the primary partition.</para>

    <para>The specifiers used in this example are:</para>

    <variablelist>
      <varlistentry>
	<term><literal>method{ format }</literal></term>
        <listitem><para>Used to make the partition be formatted.  To
        keep the content of an existing partition, change
        <literal>format</literal> to <literal>keep</literal>. For swap
        partitions, change it to
        <literal>swap</literal>.</para></listitem>
      </varlistentry>
      <varlistentry>
	<term><literal>format{ }</literal></term>
        <listitem><para>Also needed to make the partition be
        formatted.</para></listitem>
      </varlistentry>
      <varlistentry>
	<term><literal>use_filesystem{ }</literal></term>
        <listitem><para>Specifies that the partition has a filesystem
        on it.</para></listitem>
      </varlistentry>
      <varlistentry>
	<term><literal>filesystem{ ext3 }</literal></term>
        <listitem><para>Specifies the filesystem to put on the
        partition.</para></listitem>
      </varlistentry>
      <varlistentry>
	<term><literal>mountpoint { / }</literal></term>
        <listitem><para>Where to mount the partition.</para></listitem>
      </varlistentry>
    </variablelist>

    <para>Not used in the example, but useful for servers:</para>

    <variablelist>
      <varlistentry>
	<term><literal>options/noatime{ noatime - do not update inode access times at each access }</literal></term>
        <listitem><para>Mount the partition with the
        <literal>noatime</literal> mount option.  This is valid at
        least for ext3 and xfs.</para></listitem>
      </varlistentry>
    </variablelist>

    <para>Here is another example; this time there is a smaller root
    partition, and a separate <filename>/home</filename>
    partition.</para>

    <programlisting>partman-auto/text/home_scheme ::

300 4000 7000 ext3
        $primary{ }
        $bootable{ }
        method{ format }
        format{ }
        use_filesystem{ }
        filesystem{ ext3 }
        mountpoint{ / } .

64 512 300% linux-swap
        method{ swap }
        format{ } .

100 10000 1000000000 ext3
        method{ format }
        format{ }
        use_filesystem{ }
        filesystem{ ext3 }
        mountpoint{ /home } .</programlisting>

    <para>Notice that the partitions will be created in the order they
    are defined in the recipe.</para>
  </section>

  <section>
    <title>Architecture Depentent Recipes</title>

    <para>Some architectures have specific requirements for their
    partitions.  For example many of them require special partitions
    to support bootloading.</para>

    <para>For example, newworld powerpc machines need a newworld boot
    partition at the start of the disk. Here is an example fragment of
    a recipe file to create one; it should come before other
    partitions in a recipe. Notice that the partition is not
    formatted.</para>

    <programlisting>1 1 1 hfs
        $bootable{ }
        method{ newworld } .</programlisting>

    <para>Another example is a netwinder, which requires a small
    <filename>/boot</filename> partition formated in revision 0
    ext2.</para>

    <programlisting>50 500 100 ext2
        $primary{ }
        $bootable{ }
        method{ format }
        format{ }
        use_filesystem{ }
        filesystem{ ext2r0 }
        mountpoint{ /boot } .</programlisting>

    <para>And finally, an example of how to set up the efi boot
    partition needed on ia64.</para>

    <programlisting>100 100 150 fat16
        $primary{ }
        method{ efi }
        format{ } .</programlisting>

    <para>For other examples, see the architecture-specific recipes in
    partman-auto.</para>
  </section>

  <section>
    <title>Limitations</title>

    <para>Due to limitation of the algorithms in partman-auto, there
    must be at least one partition with high maximal size so that the
    whole free space can be used.  Usually you can give the partition
    containing /home a maximal size 1000000000 which is high enough
    for the present storage devices.  Do not use higher than
    1000000000 numbers because the shell arithmetic is limited to 31
    bits (on i386).</para>
  </section>

  <appendix>
    <title>Appendix</title>

    <para>On May 25th 2004, it was noted that on i386 systems, the
    very minimum size of a Debian installation on a classical (/,
    /usr, /usr, /home) setup was:</para>

    <simplelist>
      <member>48MB on / (6MB on /boot)</member>
      <member>77MB on /usr</member>
      <member>17MB on /var</member>
    </simplelist>

    <para>It is thus wise to use minimum values with this
    consideration in mind.</para>

    <simplelist>
      <member>#261244: 70MB are required for /var</member>
      <member>#265290: 1.8GB are not enough for / with desktop</member>
    </simplelist>
  </appendix>
</article>

Reply to: