From: Jeff Moyer <jmoyer@redhat.com>
To: "Ted Ts'o" <tytso@mit.edu>
Cc: "Martin K. Petersen" <martin.petersen@oracle.com>,
Ibragimov Rinat <ibragimovrinat@mail.ru>,
linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH][RFC]ext4 on 4k-sector drives without read-modify-write support
Date: Mon, 28 Feb 2011 16:57:30 -0500 [thread overview]
Message-ID: <x49zkpf4yb9.fsf@segfault.boston.devel.redhat.com> (raw)
In-Reply-To: <20110228212221.GH28617@thunk.org> (Ted Ts'o's message of "Mon, 28 Feb 2011 16:22:21 -0500")
"Ted Ts'o" <tytso@mit.edu> writes:
> On Mon, Feb 28, 2011 at 04:10:44PM -0500, Jeff Moyer wrote:
>> > So it there a reliable way to detect that disk drives that don't have
>> > the Read-Modify-Write logic? If that can be reflected up the I/O
>> > layer I can have mke2fs enforce that restriction, which currently we
>> > only enforce if the logical blocksize is 4k.
>>
>> That's not enough, I'm afraid. How do you deal with O_DIRECT, for
>> example?
>
> The drives do the read/modify/write, so O_DIRECT works fine from the
> OS's perspective. There is some risk of torn pages if you get a crash
> at the wrong moment, but that's true whenver you have a misaligned
> partition. (At least for the drives that do the RMW in the disk
> firmware.)
Sorry, I thought we were discussing devices that didn't do
read-modify-write:
> >> Unlike others drives with Advanced Format, it has not
> >> read-modify-write logic, so it can only operate with 4k
> >> blocks.
Also, mkp noted that the theory of operation was to issue aligned units
of 4k, but using 512 byte addressing. So, unless you want to keep a
blacklist AND write a remapping layer, I'd say don't buy those drives.
Cheers,
Jeff
next prev parent reply other threads:[~2011-02-28 21:57 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-26 18:24 [PATCH][RFC]ext4 on 4k-sector drives without read-modify-write support Ibragimov Rinat
2011-02-28 14:52 ` Jeff Moyer
2011-02-28 14:58 ` Martin K. Petersen
2011-02-28 18:09 ` Ted Ts'o
2011-02-28 20:19 ` Martin K. Petersen
2011-02-28 21:05 ` Ted Ts'o
2011-02-28 21:10 ` Jeff Moyer
2011-02-28 21:22 ` Ted Ts'o
2011-02-28 21:57 ` Jeff Moyer [this message]
2011-03-01 15:19 ` Martin K. Petersen
2011-02-28 21:20 ` James Bottomley
2011-02-28 21:24 ` Ted Ts'o
2011-02-28 21:23 ` Martin K. Petersen
2011-02-28 22:52 ` [PATCH][RFC]ext4 on 4k-sector drives without read-modify-writesupport Ibragimov Rinat
2011-03-01 22:16 ` Ibragimov Rinat
2011-03-10 17:01 ` Ibragimov Rinat
2011-02-28 17:54 ` [PATCH][RFC]ext4 on 4k-sector drives without read-modify-write support Ibragimov Rinat
2012-09-27 11:41 ` Mike
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=x49zkpf4yb9.fsf@segfault.boston.devel.redhat.com \
--to=jmoyer@redhat.com \
--cc=ibragimovrinat@mail.ru \
--cc=linux-fsdevel@vger.kernel.org \
--cc=martin.petersen@oracle.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;
as well as URLs for NNTP newsgroup(s).