----- "Dave Chinner" <david@xxxxxxxxxxxxx> wrote: > 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. 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@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
