From: Stan Hoeppner <stan@hardwarefreak.com>
To: "Linda A. Walsh" <xfs@tlinx.org>
Cc: xfs-oss <xfs@oss.sgi.com>
Subject: Re: block sizes > 4K ?? possible w/large page support?
Date: Mon, 11 Jun 2012 08:13:15 -0500 [thread overview]
Message-ID: <4FD5EEEB.6060709@hardwarefreak.com> (raw)
In-Reply-To: <4FD5643F.5070801@tlinx.org>
On 6/10/2012 10:21 PM, Linda A. Walsh wrote:
> Is this something being thought about??
Probably not much these days, but I'm sure it's been debated much over
the years amongst many filesystem and kernel developers across all
operating system teams, including Linux, *nix, VMS, MVS, and Windows.
...
> All but 2 could benefit from a 16K block size, and 3 of them could benefit
> from a 128K block size. Wouldn't that benefit in in freeing up some space
> both on disk and in memory? Just a thought.
If you could increase the page size and thus the XFS block size to some
arbitrarily high number such as 64KB, it would do nothing for on disk
layout but increase wasted disk sectors. It would increase transfer
performance on some workloads, but it would also cause a myriad of
problems. Not least of which is the need to recode, debug, and
regression test the entire x86[64] kernel to use properly use 64KB
pages, which I assume is no small task.
Everything is a tradeoff Linda. At this point, 4KB appears to be the
best tradeoff. And again, even if it were increased, it wouldn't do
anything to benefit the case the you mention, but would actually hurt
it, because you'd end up with more wasted sectors at the end of each file.
Array controllers and disks have no awareness of the FS block size.
They simply swallow or sling 512B sectors from/to the block layer. It's
the block layer that can benefit from being fed larger FS blocks as it
can schedule transfers more efficiently. For instance, allowing the
elevator the potential to order sector accesses, minimizing head seeks.
--
Stan
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2012-06-11 13:13 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-11 3:21 block sizes > 4K ?? possible w/large page support? Linda A. Walsh
2012-06-11 13:13 ` Stan Hoeppner [this message]
2012-06-11 13:29 ` Carlos Maiolino
2012-06-11 14:54 ` Stan Hoeppner
2012-06-11 16:21 ` Carlos Maiolino
2012-06-11 21:25 ` Stefan Ring
2012-06-11 23:56 ` Dave Chinner
2012-06-12 0:08 ` Dave Chinner
2012-06-12 2:32 ` Eric Sandeen
2012-06-12 17:37 ` Linda A. Walsh
2012-06-12 18:55 ` Eric Sandeen
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=4FD5EEEB.6060709@hardwarefreak.com \
--to=stan@hardwarefreak.com \
--cc=xfs@oss.sgi.com \
--cc=xfs@tlinx.org \
/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