From: Jeff Garzik <jgarzik@pobox.com>
To: Arvydas Sidorenko <asido4@gmail.com>
Cc: Hugh Dickins <hughd@google.com>,
Zheng Liu <wenqing.lz@taobao.com>,
linux-kernel@vger.kernel.org,
IDE/ATA development list <linux-ide@vger.kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: Storage related regression in linux-next 20120824
Date: Sun, 09 Sep 2012 16:28:19 -0400 [thread overview]
Message-ID: <504CFBE3.401@pobox.com> (raw)
In-Reply-To: <CA+6av4=6WeLcde5me2FCpBtQJAOTtHZvf4pkMExgMW9agVNLWg@mail.gmail.com>
On 09/09/2012 04:11 PM, Arvydas Sidorenko wrote:
>> I think you know your way around SCSI/libata much better than I do.
>>
>> I just bisected linux-next, and it comes down to the commit below, which
>> introduces the regression for me, and I'm guessing for you also. Maybe
>> it can be fixed up to satisfy us, but otherwise will have to be reverted:
>> we don't invert a default if it's going to break older working systems.
>>
>> A good workaround for me meanwhile is to add boot option "libata.fua=0":
>> please try that (or reverting the commit) and let us know the result.
>>
>> Thanks,
>> Hugh
>>
>> commit 91895b786e631ab47b618c901231f22b5a44115b
>> Author: Zheng Liu <wenqing.lz@taobao.com>
>> Date: Tue May 8 11:24:03 2012 +0800
>>
>> libata: enable SATA disk fua detection on default
>>
>> Currently, SATA disk fua detection is disabled on default because most of
>> devices don't support this feature at that time. With the development of
>> technology, more and more SATA disks support this feature. So now we can enable
>> this detection on default.
>>
>> Although fua detection is defined as a kernel module parameter, it is too hard
>> to set its value because it must be loaded and set before system starts up.
>> That needs to modify initrd file. So it is inconvenient for administrator who
>> needs to manage a huge number of servers.
>>
>> Signed-off-by: Zheng Liu <wenqing.lz@taobao.com>
>> Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
>>
>> diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
>> index 5eee1c1..c3fbdca 100644
>> --- a/drivers/ata/libata-core.c
>> +++ b/drivers/ata/libata-core.c
>> @@ -135,9 +135,9 @@ int atapi_passthru16 = 1;
>> module_param(atapi_passthru16, int, 0444);
>> MODULE_PARM_DESC(atapi_passthru16, "Enable ATA_16 passthru for ATAPI devices (0=off, 1=on [default])");
>>
>> -int libata_fua = 0;
>> +int libata_fua = 1;
>> module_param_named(fua, libata_fua, int, 0444);
>> -MODULE_PARM_DESC(fua, "FUA support (0=off [default], 1=on)");
>> +MODULE_PARM_DESC(fua, "FUA support (0=off, 1=on [default])");
>>
>> static int ata_ignore_hpa;
>> module_param_named(ignore_hpa, ata_ignore_hpa, int, 0644);
>
> Indeed, disabling FUA explicitly solved the issue on my disk as well.
> Hugh, what hard drive you have this issue on?
>
> I believe there are two solutions:
> - Revert FUA default back to '0'
> - Start filling SATA drive blacklist in function:
I think the right thing to do for release is disable it (again), then we
can try again later with better logic.
I'll send Linus a patch to disable.
It is entirely possible that this is a software problem, where we
missing some detail turning on FUA (thereby engaging some less traveled
core block layer machinery), or even a remote possibility of triggering
a filesystem bug.
Jeff
next prev parent reply other threads:[~2012-09-09 20:28 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-27 8:59 Storage related regression in linux-next 20120824 Arvydas Sidorenko
2012-08-27 14:40 ` Jeff Garzik
2012-08-27 16:39 ` Dieter Ries
2012-08-29 21:58 ` Storage regression in v3.6-rc3 was: " Dieter Ries
2012-08-27 16:39 ` Arvydas Sidorenko
2012-08-27 17:56 ` Arvydas Sidorenko
2012-09-09 7:38 ` Hugh Dickins
2012-09-09 20:11 ` Arvydas Sidorenko
2012-09-09 20:28 ` Jeff Garzik [this message]
2012-09-09 20:36 ` Hugh Dickins
2012-09-09 20:50 ` Jeff Garzik
2012-09-12 4:36 ` Zheng Liu
2012-09-10 17:43 ` Hugh Dickins
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=504CFBE3.401@pobox.com \
--to=jgarzik@pobox.com \
--cc=asido4@gmail.com \
--cc=hughd@google.com \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=wenqing.lz@taobao.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).