From: Matthias Schniedermeyer <ms@citd.de>
To: Stan Hoeppner <stan@hardwarefreak.com>
Cc: xfs@oss.sgi.com
Subject: Re: External log size limitations
Date: Sat, 19 Feb 2011 11:02:07 +0100 [thread overview]
Message-ID: <20110219100207.GA24537@citd.de> (raw)
In-Reply-To: <4D5F3EBF.3030309@hardwarefreak.com>
On 18.02.2011 21:53, Stan Hoeppner wrote:
> Fist, sorry for the length. I can tend to get windy talking shop. :)
>
> Andrew Klaassen put forth on 2/18/2011 2:31 PM:
>
> > It's IBM and LSI gear, so I'm crossing my fingers that a Linux install
> > will be relatively painless.
>
> Ahh, good. At least, so far it seems so. ;)
>
> > I thought that the filesystem block size was still limited to the kernel
> > page size, which is 4K on x86 systems.
> >
> > http://oss.sgi.com/projects/xfs/
> >
> > "The maximum filesystem block size is the page size of the kernel, which
> > is 4K on x86 architecture."
> >
> > Is this no longer true? It would be awesome news if it wasn't.
>
> My mistake. It would appear you are limited to the page size, which, as
> I mentioned, is still 8 KiB for most distros.
You confuse that with STACK-size.
The page-size is, and has always been, 4 KiB (on X86).
The only exception are the Huge-Pages and while i 'grep'ped for
Huge-pages i found this nice little paragraph in:
Documentation/vm/hugetlbpage.txt (Current git version on it's way to 2.6.38)
- snip -
The intent of this file is to give a brief summary of hugetlbpage support in
the Linux kernel. This support is built on top of multiple page size support
that is provided by most modern architectures. For example, i386
architecture supports 4K and 4M (2M in PAE mode) page sizes, ia64
architecture supports multiple page sizes 4K, 8K, 64K, 256K, 1M, 4M, 16M,
256M and ppc64 supports 4K and 16M. A TLB is a cache of virtual-to-physical
translations. Typically this is a very scarce resource on processor.
Operating systems try to make best use of limited number of TLB resources.
This optimization is more critical now as bigger and bigger physical memories
(several GBs) are more readily available.
- snip -
Bis denn
--
Real Programmers consider "what you see is what you get" to be just as
bad a concept in Text Editors as it is in women. No, the Real Programmer
wants a "you asked for it, you got it" text editor -- complicated,
cryptic, powerful, unforgiving, dangerous.
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2011-02-19 9:59 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-16 18:54 External log size limitations Andrew Klaassen
2011-02-17 0:32 ` Dave Chinner
2011-02-18 15:26 ` Andrew Klaassen
2011-02-18 19:55 ` Stan Hoeppner
2011-02-18 20:31 ` Andrew Klaassen
2011-02-19 3:53 ` Stan Hoeppner
2011-02-19 10:02 ` Matthias Schniedermeyer [this message]
2011-02-19 20:33 ` Stan Hoeppner
2011-02-19 21:47 ` Emmanuel Florac
2011-02-20 21:14 ` Dave Chinner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110219100207.GA24537@citd.de \
--to=ms@citd.de \
--cc=stan@hardwarefreak.com \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox