From: "Martin K. Petersen" <martin.petersen@oracle.com>
To: Boaz Harrosh <boaz@plexistor.com>
Cc: "Martin K. Petersen" <martin.petersen@oracle.com>,
Jens Axboe <axboe@fb.com>, Matthew Wilcox <willy@linux.intel.com>,
Dmitry Monakhov <dmonakhov@openvz.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
Karel Zak <kzak@redhat.com>
Subject: Re: [PATCH 4/5] brd: Request from fdisk 4k alignment
Date: Mon, 10 Nov 2014 12:00:11 -0500 [thread overview]
Message-ID: <yq1389r6les.fsf@sermon.lab.mkp.net> (raw)
In-Reply-To: <545FA9D4.5080908@plexistor.com> (Boaz Harrosh's message of "Sun, 09 Nov 2014 19:52:20 +0200")
>>>>> "Boaz" == Boaz Harrosh <boaz@plexistor.com> writes:
Boaz> I do not know why I thought that only io_min does that, I can see
Boaz> now that both effect the Kernel the same way. Which scares me a
Boaz> bit.
The difference is subtle. io_min is a hint from the storage about its
preferred minimum I/O size. pbs describes the smallest unit that can be
atomically written (like a sector on a drive with 512-byte logical/4K
physical blocks). In most cases they are the same, pbs is just a
slightly harder guarantee than io_min.
What I was objecting to in your patch description was mostly the
statement you made that these values affect kernel behavior. They really
don't. Not directly, anyway. The queue limits are stacked and offsets
are adjusted based on partitions, etc. But they don't alter the kernel
runtime behavior.
The queue limits are reported to userland and will affect things like
partitioning, MD/DM tooling and mkfs.*. And therefore they only
indirectly affect the kernel's behavior.
--
Martin K. Petersen Oracle Linux Engineering
next prev parent reply other threads:[~2014-11-10 17:00 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-05 14:00 [PATCHSET 0/5 v3] brd: partition fixes Boaz Harrosh
2014-11-05 14:01 ` [PATCH 1/5] axonram: Fix bug in direct_access Boaz Harrosh
2014-11-05 14:02 ` [PATCH 2/5] block: Change direct_access calling convention Boaz Harrosh
2014-11-05 14:04 ` [PATCH 3/5] brd: Fix all partitions BUGs Boaz Harrosh
2014-11-05 14:08 ` [PATCH 4/5] brd: Request from fdisk 4k alignment Boaz Harrosh
2014-11-05 14:20 ` Martin K. Petersen
2014-11-05 14:43 ` Boaz Harrosh
2014-11-06 17:25 ` Martin K. Petersen
2014-11-07 9:10 ` Karel Zak
2014-11-09 17:52 ` Boaz Harrosh
2014-11-10 17:00 ` Martin K. Petersen [this message]
2014-11-05 14:10 ` [PATCH 5/5] brd: Add getgeo to block ops for fdisk Boaz Harrosh
2014-11-05 15:14 ` [PATCH 5/5 v4] " Boaz Harrosh
2014-11-05 15:18 ` Boaz Harrosh
2014-11-07 9:23 ` [PATCH 5/5] " Karel Zak
2014-11-09 16:57 ` Boaz Harrosh
2014-11-10 9:58 ` Karel Zak
2014-11-10 11:15 ` Boaz Harrosh
2014-11-10 13:26 ` Karel Zak
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=yq1389r6les.fsf@sermon.lab.mkp.net \
--to=martin.petersen@oracle.com \
--cc=axboe@fb.com \
--cc=boaz@plexistor.com \
--cc=dmonakhov@openvz.org \
--cc=kzak@redhat.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=willy@linux.intel.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).