[PATCH] xfsdocs: updates to XFS User Guide

[Dave Chinner]

On Fri, Jul 09, 2010 at 12:52:20AM -0400, Lachlan McIlroy wrote:
> 
> ----- "Eric Sandeen" <sandeen at sandeen.net> wrote:
> 
> > On 07/02/2010 02:14 AM, Lachlan McIlroy wrote:
> > >  			<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!

Max file size on 32bit is 16TB.  Same reason the max filesystem size is limited
to 16TB on 32 bit  - the page cache address limit. 

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

Yup, correct.

> I'll just leave it as 8GB.

As most people will just use defaults, that's fine ;)

> > > -		<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.

IIRC, just add and commit them like normal text files.

> 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.

"The inode’s number is derived from its location on disk"

> > > +		</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?

Sure - it changes allocator behaviour for the better, and if applications use
stat64 then there isn't a problem...

Cheers,

Dave.
-- 
Dave Chinner
david at fromorbit.com