Messages in this thread | | | Date | Sun, 09 Sep 2012 16:28:19 -0400 | From | Jeff Garzik <> | Subject | Re: Storage related regression in linux-next 20120824 |
| |
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
| |