xfs
[Top] [All Lists]

Re: [PATCH] xfsdocs: updates to XFS User Guide

To: Eric Sandeen <sandeen@xxxxxxxxxxx>
Subject: Re: [PATCH] xfsdocs: updates to XFS User Guide
From: Lachlan McIlroy <lmcilroy@xxxxxxxxxx>
Date: Fri, 9 Jul 2010 00:52:20 -0400 (EDT)
Cc: xfs@xxxxxxxxxxx
In-reply-to: <692684202.1117291278650941725.JavaMail.root@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Reply-to: Lachlan McIlroy <lmcilroy@xxxxxxxxxx>
----- "Eric Sandeen" <sandeen@xxxxxxxxxxx> wrote:

> On 07/02/2010 02:14 AM, Lachlan McIlroy wrote:
> > Hi all, it's been a while since I posted here!
> > 
> > Various updates to chapters 1,2,4 and 5 of the XFS User Guide.
> > 
> > Fixed various spelling/grammar mistakes, updated outdated and/or
> > incorrect facts, added some new slides for delayed allocation and
> > direct i/o and fixed some XML formatting for command line examples.
> 
> Thanks!  I'd been feeling bad about not updating this ;)

Me too.  I've been sitting on these changes for a while.

> 
> Some comments below.
> 
> > Lachlan
> > 
> > 
> > diff --git a/XFS_User_Guide/en-US/XFS-Background.xml
> b/XFS_User_Guide/en-US/XFS-Background.xml
> > index e20f6e0..bdf6910 100644
> > --- a/XFS_User_Guide/en-US/XFS-Background.xml
> > +++ b/XFS_User_Guide/en-US/XFS-Background.xml
> > @@ -195,12 +195,12 @@
> >                     </listitem>
> >                     <listitem>
> >                             <para>
> > -                                   Large filesystems: one terabyte,
> 2<superscript>40</superscript>, on 32 bit systems; unlimited on 64 bit
> systems
> > +                                   Large files: up to 9 ExaBytes.
> >                             </para>
> >                     </listitem>
> >                     <listitem>
> >                             <para>
> > -                                   Large files: one terabyte, 
> > 2<superscript>40</superscript>, on
> 32 bit systems; 2<superscript>63</superscript> on 64 bit systems
> > +                                   Large filesystems: up to 18 ExaBytes.
> >                             </para>
> 
> *shrug* I guess it's ok to remove the 32-bit specification, but why?
> (not that they had corect numbers before ...)

I was just trying to keep the brief brief ...and I couldn't get a definitive
answer for 32 bits.  I assume the 1TB limit comes from 2^31 * 2^9 byte sectors
but what about 4KB sectors?  Does that make it 8TB?  I wouldn't want to let
ext3/4 look better here!

> 
> 
> > diff --git a/XFS_User_Guide/en-US/XFS-Overview.xml
> b/XFS_User_Guide/en-US/XFS-Overview.xml
> > index 1762b39..796729b 100644
> > --- a/XFS_User_Guide/en-US/XFS-Overview.xml
> > +++ b/XFS_User_Guide/en-US/XFS-Overview.xml
> > @@ -52,7 +52,7 @@
> >             <itemizedlist>
> >             <listitem><para>Filesystem blocks are comprised of one or more
> device-level sectors.</para></listitem>
> >             </itemizedlist>
> > -           <para>The page management implementation in Linux limits the FSB
> size to the page size</para>
> > +           <para>The page management implementation in Linux limits the
> maximum FSB size to the page size</para>
> >             <itemizedlist>
> >             <listitem><para>4KB on ia32 and x86_64
> architectures</para></listitem>
> >             <listitem><para>16KB on ia64</para></listitem>
> > @@ -66,13 +66,19 @@
> >             <title>Extents</title>
> >             <para>An extent is a set of one or more contiguous FSBs that
> define a region in the filesystem for file data or metadata</para>
> >             <itemizedlist>
> > -           <listitem><para>A single extent can be up to 8GB in
> length</para></listitem>
> > +           <listitem><para>A single extent can be up to 4GB in
> length</para></listitem>
> 
> I'm sure you're right but just for my sanity can you remind me
> when/why/if this changed?

I could have sworn I was told 4GB in the past and that it's a limit imposed
by a unsigned 32-bit length field somewhere.  Looks like I am mistaken and
there's 21 bits for the length (in blocks) so it is 8GB for a 4KB block
size... and up to 128GB for 64KB block size?  I'll just leave it as 8GB.

> 
> 
> > diff --git a/XFS_User_Guide/en-US/XFS-mkfs.xml
> b/XFS_User_Guide/en-US/XFS-mkfs.xml
> > index ce26572..adb12bd 100644
> > --- a/XFS_User_Guide/en-US/XFS-mkfs.xml
> > +++ b/XFS_User_Guide/en-US/XFS-mkfs.xml
> > @@ -5,7 +5,7 @@
> >     <title>mkfs</title>
> >     <section>
> >             <title>Creating XFS Filesystems</title>
> > -           <para>mkfs.xfs supports a large number of options for
> configuration a large number of different XFS filesystems</para>
> > +           <para>mkfs.xfs supports a large number of options for
> configurating many different XFS filesystems</para>
> 
> s/configurating/configuring/ ?

Hmmm, did I just invent a new word?  Sounds like it should be a word!
Thanks, fixed.

> 
> 
> > @@ -103,9 +108,8 @@
> >             <itemizedlist>
> >             <listitem><para>15K RPM disk or battery-backed
> memory</para></listitem>
> >             </itemizedlist>
> > -           <para><command>mkfs.xfs -l logdev=log_device
> device</command></para>
> > -           <para><command>mount -o logdev=log_device device
> path</command></para>
> > -           <para>XXX Image goes here</para>
> 
> hm probably need to pull in those images some day :(

I did pull over some images but I don't know how to push them
into git.

> 
> > diff --git a/XFS_User_Guide/en-US/XFS-mount.xml
> b/XFS_User_Guide/en-US/XFS-mount.xml
> > index e175f95..91cd4dc 100644
> > --- a/XFS_User_Guide/en-US/XFS-mount.xml
> > +++ b/XFS_User_Guide/en-US/XFS-mount.xml
> > @@ -25,37 +25,41 @@
> >     <section>
> >             <title>Mount Options - Log &amp; Realtime Devices</title>
> >             <para>Use an external log (metadata journal) device:</para>
> > -           <para><command>mount -o logdev=log_device device
> mountpoint</command></para>
> > +           <para><command>mount -o
> logdev=<replaceable>log_device</replaceable>
> <replaceable>device</replaceable>
> <replaceable>mountpoint</replaceable></command></para>
> >             <para>Use an external log (metadata journal) and real-time
> device:</para>
> > -           <para><command>mount -o logdev=log_device,rtdev=rt_device device
> mountpoint</command></para>
> > +           <para><command>mount -o
> logdev=<replaceable>log_device</replaceable>,rtdev=<replaceable>rt_device</replaceable>
> <replaceable>device</replaceable>
> <replaceable>mountpoint</replaceable></command></para>
> >     </section>
> >     <section>
> > -           <title>Mount Options - 64bit Inodes</title>
> > -           <para>By default XFS uses 32bit inodes</para>
> > -           <itemizedlist>
> > -           <listitem><para>The inode’s number roughly equates to its
> location on disk
> > +           <title>Mount Options - 32 or 64 bit Inodes?</title>
> 
> Hm the other <title>s for mount options don't ask questions ...

Okay, no questions in titles.

> 
> > +           <para>The inode’s number roughly equates to its location on disk
> 
> hm, really, it exactly equates, but whatever ;)

Isn't it a combination of AG-number/AG-offset rather than a logical block
from the start of the filesystem?  I think that's the distinction the 'roughly'
is referring to.

> 
> >                     <itemiz>                </itemizedlist>
> >             <para>See</para>
> >             <itemizedlist>
> > @@ -170,12 +179,13 @@
> >     <section>
> >             <title>Mount Options - User/Group/Project Quotas</title>
> >             <para>User disk quota accounting enabled, and limits 
> > (optionally)
> enforced.</para>
> > -           <para><command>mount -o uquota device
> mountpoint</command></para>
> > +           <para><command>mount -o uquota <replaceable>device</replaceable>
> <replaceable>mountpoint</replaceable></command></para>
> >             <para>Group disk quota accounting enabled, and limits
> (optionally) enforced.</para>
> > -           <para><command>mount -o grpquota device
> mountpoint</command></para>
> > +           <para><command>mount -o grpquota
> <replaceable>device</replaceable>
> <replaceable>mountpoint</replaceable></command></para>
> >             <para>Project quota accounting enabled, and limits (optionally)
> enforced.</para>
> > -           <para><command>mount -o prjquota device
> mountpoint</command></para>
> > -           <para>Can optionally specify <command>uqnoenforce,
> gqnoenforce</command> and 
> > -                 <command>pqnoenforce</command> to use soft limits.</para>
> > +           <para><command>mount -o prjquota
> <replaceable>device</replaceable>
> <replaceable>mountpoint</replaceable></command></para>
> > +           <para>Can optionally specify <command>uqnoenforce</command>, 
> > +                   <command>gqnoenforce</command> and
> <command>pqnoenforce</command> 
> > +                   to use soft limits.</para>
> >     </section>
> >  </chapter>
> > 
> > _______________________________________________
> > xfs mailing list
> > xfs@xxxxxxxxxxx
> > http://oss.sgi.com/mailman/listinfo/xfs
> 
> edlist>
> >                     <listitem><para>Combination of allocation group, 
> > cluster and
> block</para></listitem>
> >                     </itemizedlist>
> > -           </para></listitem>
> > -           <listitem><para>Inode on Linux is 32bit on 32bit machines
> > +           </para>
> > +           <para>32 bit inodes (default):</para>
> > +           <itemizedlist>
> > +           <listitem><para>Must use 32bit inodes on 32bit machines
> 
> I don't think this is true anymore?  Christoph?

You can mount with inode64 on a 32-bit machine if that's what you mean.
But does it make sense?

> 
> 
> > @@ -65,8 +69,8 @@
> >             <para>Specify the stripe unit and width for a RAID device or a
> stripe volume.</para>
> >             <para>Values must be specified in 512-byte block units.</para>
> >             <para>For example, to use a stripe unit of 1MB and a stripe 
> > width
> of 8MB:</para>
> > -           <para><command>mount -o sunit=2048,swidth=16384 device
> mountpoint</command></para>
> > -           <para><command>swalloc</command> option</para>
> > +           <para><command>mount -o sunit=2048,swidth=16384
> <replaceable>device</replaceable>
> <replaceable>mountpoint</replaceable></command></para>
> > +           <para><command>swalloc</command> mount option</para>
> 
> hmm next time sending a patch just for the <replaceable> changes
> would
> make review easier ...

Yeah okay will do (the thought occured to me but I just wanted to get these
changes out).

> 
> 
> > -           <para><command>ikeep</command></para>
> > +           <para><command>ikeep</command> (default)</para>
> >             <itemizedlist>
> >             <listitem><para>When inode clusters are emptied of inodes, keep
> them around on the disk.</para></listitem>
> > +           <listitem><para>Use the <command>noikeep</command> option to
> force empty inode clusters to be returned to
> > +                   the free space pool.</para></listitem>
> 
> wait, ikeep isn't the default.....

Did we change it again?  I'll just remove the default tag.

> 
> 
> > -           <listitem><para>Filesystem will attempt to determine is barriers
> are supported and will 
> > +           <listitem><para>Filesystem will attempt to determine if barriers
> are supported and will 
> >                             issue a warning to the syslog if they are
> not</para></listitem>
> >             <listitem><para>The <command>nobarrier</command> option disables
> write barriers</para></listitem>
> > +           <listitem><para>Barriers should be disabled when using a RAID
> with battery backed controller
> > +                   cache (but only if the individual disk write caches are
> disabled)</para></listitem>
> 
> we've been going back and forth on that a little, we lose queue
> ordering
> barriers too with nobarrier ...

I understand the problem with the drive caches but what does queue ordering
give us?  Should I just leave this change out?  

<Prev in Thread] Current Thread [Next in Thread>