From patchwork Sat Dec 1 06:21:43 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Juha-Matti Tilli X-Patchwork-Id: 1006308 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=vger.kernel.org (client-ip=209.132.180.67; helo=vger.kernel.org; envelope-from=linux-ide-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dmarc=fail (p=none dis=none) header.from=iki.fi Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 436Lkw4Bj5z9s9G for ; Sat, 1 Dec 2018 17:22:00 +1100 (AEDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726264AbeLARdp (ORCPT ); Sat, 1 Dec 2018 12:33:45 -0500 Received: from mail-ed1-f66.google.com ([209.85.208.66]:47071 "EHLO mail-ed1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726124AbeLARdp (ORCPT ); Sat, 1 Dec 2018 12:33:45 -0500 Received: by mail-ed1-f66.google.com with SMTP id o10so6556840edt.13 for ; Fri, 30 Nov 2018 22:21:58 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=ONG7y+D/Lff1mdJJduJ5dwoaJuCah9pBsViUhiNeHj8=; b=hv/h7x636GlO2RQSaYd9x4S4i905G8/R1pz/2M0YrMP/G6AB7h+dV0hYL4xWqRnAJU MlxF1/wFKZzYU1j3X8Bf2ic0S7G7YAzRSDakzvAQMfWI0khGcnAIE+FxOzvCJFdomQSu 8XhNvVCjNaxp+zJf4zt556nA+oBJFa8YxqcVqdDCGKo8nrhp23aSFet2WOBvYvt4DKZp ND1ZVvAy6ZEOaGb+GmM8e0fbXiTg/ZwGUqiPf2PyMHZxtWKQ1fuybl91tJMD8szlyn27 ap6z9yevri11rEE5S6kC/8afRZM6msIa/4RVXwQEPOVjF6bgfeECfI+ypH8d7Fnzk2P/ /n+A== X-Gm-Message-State: AA+aEWYuMIerXSMluS6JsrWbWvIwRqdyRlYXFnvyQloSWXEEXFZDh28A xdHi2ICuMFRodt/74DwFMIPB35qgiDM= X-Google-Smtp-Source: AFSGD/XSWjvvZSMId4LAhF7NcnvyzmVm6nFeEIkUALKQqEJai5FIjWrCD6HTTEMIHsrue1S68lt6Zw== X-Received: by 2002:a17:906:7751:: with SMTP id o17-v6mr6657349ejn.15.1543645316936; Fri, 30 Nov 2018 22:21:56 -0800 (PST) Received: from mail-wr1-f45.google.com (mail-wr1-f45.google.com. [209.85.221.45]) by smtp.gmail.com with ESMTPSA id 24sm1909347eds.97.2018.11.30.22.21.56 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 30 Nov 2018 22:21:56 -0800 (PST) Received: by mail-wr1-f45.google.com with SMTP id j10so7207325wru.4 for ; Fri, 30 Nov 2018 22:21:56 -0800 (PST) X-Received: by 2002:adf:a743:: with SMTP id e3mr6996770wrd.56.1543645316179; Fri, 30 Nov 2018 22:21:56 -0800 (PST) MIME-Version: 1.0 From: Juha-Matti Tilli Date: Sat, 1 Dec 2018 08:21:43 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: [PATCH] Samsung MZ7KM SSD zero after TRIM To: linux-ide@vger.kernel.org Sender: linux-ide-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ide@vger.kernel.org Hello, (I'm not on the list, please CC me if you want a reply. Sorry if this is a repost, I think my first message didn't get through as it was multipart and not plain text.) The Samsung MZ7KM series devices that support ZERO after TRIM do not support TRIM in RAID4/5/6 even if the special module parameter is enabled. The reason is that the device name includes SAMSUNG but it does not include SSD even though these server-grade storage devices are actually SSDs. The whitelist contains only Samsung*SSD* and SAMSUNG*SSD*. The whitelist should contain SAMSUNG*MZ7KM* as well. An alternative would be SAMSUNG* but then that would match HDDs as well. Not sure if this has negative effects; in my current patch, I only whitelist the MZ7KM devices. We tested with RAID1 that these SSDs genuinely read zero after TRIM by writing a large file with random data, observing the data is present on the physical disks, removing the file and running fstrim, and observing the data is now zero on the physical disks. The device reports to read zero after TRIM to the operating system, as well, but the operating system doesn't believe the device. Because of our tests, I think the device should be believed to report the flag correctly. For RAID1, the reads zero after TRIM flag is not needed, but unfortunately, we have too much data to economically store it in RAID-1 with three disks per mirror, and two disks per mirror would be too dangerous because two failures could disable the array. As far as I know, this problem affects all versions of the Linux kernel. Currently we have to run a custom manually compiled kernel with the patch, because our use case is severely affected by lack of TRIM support (lots of data stored, lots of I/O, nearly full disks, less than megabyte average file size, 1 DWPD order of magnitude, uneconomical to use RAID-1 on the storage server). I reported this to Red Hat Bugzilla, but they wanted me to report this first to this list, before the patch can be applied to Red Hat. Patch is here, sorry I use Gmail so I can't send the patch as a separate git-send-email message given my current mail system: From: Juha-Matti Tilli Date: Wed, 21 Nov 2018 10:30:00 +0200 Subject: [PATCH] Samsung MZ7KM SSDs read zero after TRIM --- drivers/ata/libata-core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c index b289128..9d25932 100644 --- a/drivers/ata/libata-core.c +++ b/drivers/ata/libata-core.c @@ -4247,6 +4247,7 @@ { "SSD*INTEL*", NULL, ATA_HORKAGE_ZERO_AFTER_TRIM, }, { "Samsung*SSD*", NULL, ATA_HORKAGE_ZERO_AFTER_TRIM, }, { "SAMSUNG*SSD*", NULL, ATA_HORKAGE_ZERO_AFTER_TRIM, }, + { "SAMSUNG*MZ7KM*", NULL, ATA_HORKAGE_ZERO_AFTER_TRIM, }, { "ST[1248][0248]0[FH]*", NULL, ATA_HORKAGE_ZERO_AFTER_TRIM, }, /*