xfs
[Top] [All Lists]

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

To: Lachlan McIlroy <lmcilroy@xxxxxxxxxx>
Subject: Re: [PATCH] xfsdocs: updates to XFS User Guide
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Fri, 9 Jul 2010 16:39:18 +1000
Cc: Eric Sandeen <sandeen@xxxxxxxxxxx>, xfs@xxxxxxxxxxx
In-reply-to: <924144750.1117311278651140228.JavaMail.root@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
References: <692684202.1117291278650941725.JavaMail.root@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <924144750.1117311278651140228.JavaMail.root@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
User-agent: Mutt/1.5.20 (2009-06-14)
On Fri, Jul 09, 2010 at 12:52:20AM -0400, Lachlan McIlroy wrote:
> 
> ----- "Eric Sandeen" <sandeen@xxxxxxxxxxx> 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@xxxxxxxxxxxxx

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