From: "Martin K. Petersen" <martin.petersen@oracle.com>
To: "Ted Ts'o" <tytso@mit.edu>
Cc: Mike Snitzer <snitzer@redhat.com>,
Eric Sandeen <sandeen@redhat.com>,
Jens Axboe <jaxboe@fusionio.com>,
"Martin K. Petersen" <martin.petersen@oracle.com>,
"James.Bottomley\@hansenpartnership.com"
<James.Bottomley@hansenpartnership.com>,
"linux-scsi\@vger.kernel.org" <linux-scsi@vger.kernel.org>,
"linux-ext4\@vger.kernel.org" <linux-ext4@vger.kernel.org>
Subject: Re: I/O topology fixes for big physical block size
Date: Tue, 28 Sep 2010 17:24:56 -0400 [thread overview]
Message-ID: <yq162xpa7dj.fsf@sermon.lab.mkp.net> (raw)
In-Reply-To: <20100928205741.GA22257@thunk.org> (Ted Ts'o's message of "Tue, 28 Sep 2010 16:57:41 -0400")
>>>>> "Ted" == Ted Ts'o <tytso@mit.edu> writes:
Ted> Can we decide soon what the right thing should be? I'm about to
Ted> release e2fsrogs 1.41.13, and if I should put in some sanity
Ted> checking code so mke2fs does something sane when it sees a 1M
Ted> physical block size, I can do that.
I don't think it's entirely clear what the "right thing" would be.
Let's ignore the 1MB block size for now. That's clearly a fluke and a
buggy device. But there are SSDs that will advertise an 8KiB physical
block size. And apparently 16KiB devices are in the pipeline.
How do we want to handle these devices? Allowing blocks bigger than the
page size is going to be painful.
So the question is whether we can tweak the filesystem layout in a way
that would alleviate the pain without having to change the filesystem
block size in the traditional sense.
At least we're talking about SSDs and arrays here. I assume the partial
block write penalty for these devices would be smaller than it is for
rotating media.
--
Martin K. Petersen Oracle Linux Engineering
next prev parent reply other threads:[~2010-09-28 21:26 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1285605664-27027-1-git-send-email-martin.petersen@oracle.com>
[not found] ` <4CA0CC38.5010804@fusionio.com>
[not found] ` <yq1pqvzcddq.fsf@sermon.lab.mkp.net>
[not found] ` <4CA118FF.1080100@fusionio.com>
[not found] ` <yq18w2mddav.fsf@sermon.lab.mkp.net>
2010-09-27 23:15 ` I/O topology fixes for big physical block size Mike Snitzer
2010-09-28 4:30 ` Jens Axboe
2010-09-28 5:20 ` Eric Sandeen
2010-09-28 14:15 ` Mike Snitzer
2010-09-28 20:57 ` Ted Ts'o
2010-09-28 21:24 ` Martin K. Petersen [this message]
2010-09-28 21:36 ` Eric Sandeen
2010-09-30 16:30 ` Ted Ts'o
2010-09-30 17:07 ` Eric Sandeen
2010-09-30 17:33 ` Mike Snitzer
2010-10-01 14:24 ` Ted Ts'o
2010-10-01 22:19 ` Martin K. Petersen
2010-10-02 2:31 ` Ted Ts'o
2010-10-02 3:03 ` Daniel Taylor
2010-10-04 19:49 ` Martin K. Petersen
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=yq162xpa7dj.fsf@sermon.lab.mkp.net \
--to=martin.petersen@oracle.com \
--cc=James.Bottomley@hansenpartnership.com \
--cc=jaxboe@fusionio.com \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=sandeen@redhat.com \
--cc=snitzer@redhat.com \
--cc=tytso@mit.edu \
/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