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 _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
