[PATCH] xfsdocs: updates to XFS User Guide

[Lachlan McIlroy]

----- "Dave Chinner" <david at fromorbit.com> wrote:

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

Thanks Dave.  I should have known that.  And it's already there in slide 2.4!

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

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

Sweet, done.

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

Okay, great.  I'll drop that part.  Thanks.

> 
> Cheers,
> 
> Dave.
> -- 
> Dave Chinner
> david at fromorbit.com