From: Eric Sandeen <sandeen@sandeen.net>
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: Tue, 12 Jun 2012 13:55:32 -0500 [thread overview]
Message-ID: <4FD790A4.8010907@sandeen.net> (raw)
In-Reply-To: <4FD77E45.8010402@tlinx.org>
On 6/12/12 12:37 PM, Linda A. Walsh wrote:
>
>
> Eric Sandeen wrote:
>> On 6/10/12 10:21 PM, Linda A. Walsh wrote:
>>> Is this something being thought about??
>>>
>>> More than one of my hard disks:
>>>
>>> /boot: 130 files in 103112 4K blocks: 793.6 blks/file
>>> /tmp: 1401 files in 746715 4K blocks: 533.4 blks/file
>>> /var/cache: 1438 files in 87858 4K blocks: 61.5 blks/file
>>> /backups: 713 files in 2523985177 4K blocks: 3539951.6 blks/file
>>> /var: 9038 files in 746715 4K blocks: 83.1 blks/file
>>> /var/cache/squid: 570 files in 90031 4K blocks: 158.4 blks/file
>>> /Media: 51893 files in 1691400956 4K blocks: 32594.5 blks/file
>>> /: 37312 files in 506778 4K blocks: 14.0 blks/file
>>> /usr/share: 320805 files in 195425485 4K blocks: 609.6 blks/file
>>> /backups/Media: 50544 files in 1642550112 4K blocks: 32497.9 blks/file
>>> /usr: 116650 files in 1389380 4K blocks: 12.4 blks/file
>>> /Share: 1617995 files in 305269701 4K blocks: 189.1 blks/file
>>> /home: 5822174 files in 195412389 4K blocks: 34.0 blks/file
>>>
>>> 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.
>>
>> Since on average each file in an evenly-distributed filesystem wastes half
>> a block, in theory each fs would waste 4x more space w/ 16k blocks than
>> 4k blocks, right?
> ---
> Well the real candidates for a larger block size would be backups,
> and maybe Media... the rest wouldn't benefit.
>
> So, it sounds like I might just as well benefit by going to a 1K
> block size, if there's no cost in smaller block sizes? Or would that be
> entirely dependent on the files/dir?
Well, there are some metadata overhead costs there, so it's a tradeoff.
Like we always say, use the defaults unless you can definitively show
that other options work better for your needs after testing. :)
-Eric
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
prev parent reply other threads:[~2012-06-12 18:55 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
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 [this message]
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=4FD790A4.8010907@sandeen.net \
--to=sandeen@sandeen.net \
--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