----- "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 & 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?
|