linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Phillip Susi <psusi@ubuntu.com>
To: stan@hardwarefreak.com, joystick <joystick@shiftmail.org>
Cc: linux-raid <linux-raid@vger.kernel.org>
Subject: Re: The chunk size paradox
Date: Thu, 02 Jan 2014 20:02:09 -0500	[thread overview]
Message-ID: <52C60C11.30906@ubuntu.com> (raw)
In-Reply-To: <52C5F335.9060909@hardwarefreak.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 01/02/2014 06:16 PM, Stan Hoeppner wrote:
> Thank you for this information.  Now, if I actually had a 4K drive
> in my hands, and plugged it in, directly formatted it with XFS, no
> partitions, would the LBA addressing be 4K or 512B?  Or would I
> need to tweak kernel parameters?  Or possibly rebuild my kernel to
> support 4K sectors?

Addressing would be in 4k sectors, no need for tweaking.  You can see
it in action with the scsi_debug module if you don't have the actual
hardware.

> It's not relevant because you don't create an md RAID set from
> CD-ROM.

Well the context wasn't specifically for md; you claimed linux did not
support non 512 byte sectors full stop.  And you *can* build an md
raid on top of cd/dvd-rw, though obviously that's a little nutty.

> IIRC, there was a lengthy discussion about this on mm back when
> some folks wanted to use 16K-4GB pages on Itanium, and later 2M
> pages on x86-64, to cut down on the amount of memory required for
> page tables and to increase performance for big memory workloads.
> As I recall the arguments for continuing to use 4K pages across the
> world of Linux, regardless of architecture capability, and to NOT
> make it configurable as in HP-UX, were, paraphrasing:

Some archs don't support 4k pages at all.

> 1.  The kernel manipulates "everything" in pages so we need
> consistency 2.  While larger pages saves page table space and
> increases throughput for large memory intensive workloads, it
> causes more waste in other structures and increases bandwidth
> demands for data that are smaller than the page size
> 
> So, IIRC, it was decided that the page size would remain 4K
> basically forever.  So while it is *technically* possible to have a
> larger page size in Linux, it is absolutely not supported by the
> kernel team, nor any distro kernel, AFAIK.

Yep, that's why the default on those archs that have a choice is still
4k, but some do give the option for larger.  If you scan the ext4 and
md mailing lists you should find a few discussions of people doing
this, or just using larger block sizes on archs that only support
larger page sizes.

> And I'd guess a whole host of things will likely break as a result
> if you don't correctly modify much of the kernel source before
> running make.  See above.

Nope; otherwise it wouldn't be a Kconfig option.  Remember, the kernel
had to grow support for non 4k pages to work at all on archs that
don't support them.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBCgAGBQJSxgwRAAoJEI5FoCIzSKrwVBIH/2XxI7Pz7pb5ojV94Xg7om2Y
drEebKn5N+QFXQGXkMZFknFSDGuv4l/KgNmPbU43ntXmAi/U+HyepMtFl4K4tPVd
lgSxNE7oikEMgHV5mKa4Ic0iB46AUp7cuhvyGe3FVxC+co9+J8hWgr11iYCCP2ra
9d7TT2hQEHELSvzWVoYWbh7ndV9ZfB5LC6dsRlqu0OKPlkX5xg/H7jlEgpqb0/Uc
ebJ4CidYtKVMsW5My3K7uG1T4uZoB6QTNEDaYzfJjw+5KAKAR60TZXttADt670yk
BPpU55UbFZTBgUyKIuYsxIZ2mgZKNTd3BT4jWOb+J5Z3+KPbN/nuHhAWqwIE+24=
=6YGJ
-----END PGP SIGNATURE-----

  reply	other threads:[~2014-01-03  1:02 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-30 18:48 The chunk size paradox Phillip Susi
2013-12-30 23:38 ` Peter Grandi
2013-12-31  0:01   ` Wolfgang Denk
2013-12-31 13:51     ` David Brown
2014-01-02 20:08   ` Phillip Susi
2014-01-02 14:49 ` joystick
2014-01-02 15:24   ` Phillip Susi
2014-01-02 15:41   ` Stan Hoeppner
2014-01-02 16:31     ` Phillip Susi
2014-01-02 18:02       ` Stan Hoeppner
2014-01-02 19:10         ` Phillip Susi
2014-01-02 22:49           ` Peter Grandi
2014-01-02 23:16           ` Stan Hoeppner
2014-01-03  1:02             ` Phillip Susi [this message]
2014-01-02 19:21         ` Joe Landman
2014-01-02 22:42           ` Stan Hoeppner
2014-01-02 22:56             ` Carsten Aulbert
2014-01-03  0:19               ` Phillip Susi
2014-01-03  1:24               ` Stan Hoeppner
2014-01-03  3:14               ` Joe Landman
2014-01-03  3:19                 ` Stan Hoeppner
2014-01-03  4:24                   ` Stan Hoeppner
2014-01-02 23:22           ` Peter Grandi
2014-01-03  3:09             ` Joe Landman
2014-01-03  4:58             ` Joe Landman
2014-01-02 22:32         ` Wolfgang Denk
2014-01-03 14:51           ` Benjamin ESTRABAUD

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=52C60C11.30906@ubuntu.com \
    --to=psusi@ubuntu.com \
    --cc=joystick@shiftmail.org \
    --cc=linux-raid@vger.kernel.org \
    --cc=stan@hardwarefreak.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;
as well as URLs for NNTP newsgroup(s).