From owner-freebsd-fs@FreeBSD.ORG Thu Feb 6 14:37:08 2014 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E2E1C797 for ; Thu, 6 Feb 2014 14:37:06 +0000 (UTC) Received: from pi.nmdps.net (pi.nmdps.net [109.61.102.5]) by mx1.freebsd.org (Postfix) with ESMTP id 90EE81BFA for ; Thu, 6 Feb 2014 14:37:04 +0000 (UTC) Received: from pi.nmdps.net (pi.nmdps.net [109.61.102.5]) (Authenticated sender: krichy@cflinux.hu) by pi.nmdps.net (Postfix) with ESMTPSA id 1B1F8112D for ; Thu, 6 Feb 2014 15:36:57 +0100 (CET) Date: Thu, 6 Feb 2014 15:36:54 +0100 (CET) From: Richard Kojedzinszky X-X-Sender: krichy@pi.nmdps.net To: freebsd-fs@freebsd.org Subject: geom write cache handling Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="2628712688-239966612-1391696912=:61272" Content-ID: X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 14:37:08 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --2628712688-239966612-1391696912=:61272 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; format=flowed Content-ID: Dear fs team, I own an STEC SSD, which I use for ZFS SLOG. The device is broken in that if it gets a SCSI synchronize cache, it does something which is very slow. Actually with it in FreeBSD the reachable sync IOPS is around 100. When the device has write cache disabled, there is no need to send the SCSI synchronize cache commands to it, and without them I can reach 1400 IOPS. The device itself have power-loss-protection, so I risk no data corruption at all. By the way, linux behave the same, if either ata or scsi disks have their write cache turned off, it even does not send the command to the drive. Also, I have an Intel S3700, which is much faster, but have similar symptons. The drive handles synchronize cache commands much faster than STEC, maybe it is implemented in the drive as a simple NOP, but as for 4K sync writes a sync cache follows, it effectively halves the IOPS. I have it attached to a SATA2 controller only, and with WCE disabled, and sending the sync cache to it I can reach around 4500 IOPS, while disabling the sync cache it can reach >9000 IOPS. I've attached a very simple patch for the ata layer, but I dont know how to implement it for the scsi subsystem also. Regards, Kojedzinszky Richard --2628712688-239966612-1391696912=:61272 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME=geom_write_through.diff Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: ATTACHMENT; FILENAME=geom_write_through.diff ZGlmZiAtLWdpdCBhL3N5cy9jYW0vYXRhL2F0YV9kYS5jIGIvc3lzL2NhbS9h dGEvYXRhX2RhLmMNCmluZGV4IGNjMjgzMTEuLjEwZTRmOWIgMTAwNjQ0DQot LS0gYS9zeXMvY2FtL2F0YS9hdGFfZGEuYw0KKysrIGIvc3lzL2NhbS9hdGEv YXRhX2RhLmMNCkBAIC0xMjQyLDcgKzEyNDIsNyBAQCBhZGFyZWdpc3Rlcihz dHJ1Y3QgY2FtX3BlcmlwaCAqcGVyaXBoLCB2b2lkICphcmcpDQogCQltYXhp byA9IG1pbihtYXhpbywgMjU2ICogc29mdGMtPnBhcmFtcy5zZWNzaXplKTsN CiAJc29mdGMtPmRpc2stPmRfbWF4c2l6ZSA9IG1heGlvOw0KIAlzb2Z0Yy0+ ZGlzay0+ZF91bml0ID0gcGVyaXBoLT51bml0X251bWJlcjsNCi0Jc29mdGMt PmRpc2stPmRfZmxhZ3MgPSAwOw0KKwlzb2Z0Yy0+ZGlzay0+ZF9mbGFncyA9 IERJU0tGTEFHX1dSSVRFX1RIUk9VR0g7DQogCWlmIChzb2Z0Yy0+ZmxhZ3Mg JiBBREFfRkxBR19DQU5fRkxVU0hDQUNIRSkNCiAJCXNvZnRjLT5kaXNrLT5k X2ZsYWdzIHw9IERJU0tGTEFHX0NBTkZMVVNIQ0FDSEU7DQogCWlmIChzb2Z0 Yy0+ZmxhZ3MgJiBBREFfRkxBR19DQU5fVFJJTSkgew0KQEAgLTE4MzUsNiAr MTgzNSwxMiBAQCBhZGFkb25lKHN0cnVjdCBjYW1fcGVyaXBoICpwZXJpcGgs IHVuaW9uIGNjYiAqZG9uZV9jY2IpDQogCQkJfQ0KIAkJfQ0KIA0KKwkJaWYg KGF0YWlvLT5jbWQuZmVhdHVyZXMgPT0gQVRBX1NGX0VOQUJfV0NBQ0hFKSB7 DQorCQkJc29mdGMtPmRpc2stPmRfZmxhZ3MgJj0gfkRJU0tGTEFHX1dSSVRF X1RIUk9VR0g7DQorCQl9IGVsc2Ugew0KKwkJCXNvZnRjLT5kaXNrLT5kX2Zs YWdzIHw9IERJU0tGTEFHX1dSSVRFX1RIUk9VR0g7DQorCQl9DQorDQogCQlz b2Z0Yy0+c3RhdGUgPSBBREFfU1RBVEVfTk9STUFMOw0KIAkJLyoNCiAJCSAq IFNpbmNlIG91ciBwZXJpcGhlcmFsIG1heSBiZSBpbnZhbGlkYXRlZCBieSBh biBlcnJvcg0KZGlmZiAtLWdpdCBhL3N5cy9nZW9tL2dlb21fZGlzay5jIGIv c3lzL2dlb20vZ2VvbV9kaXNrLmMNCmluZGV4IDE2ZjZjNDQuLjJjYjRjZWYg MTAwNjQ0DQotLS0gYS9zeXMvZ2VvbS9nZW9tX2Rpc2suYw0KKysrIGIvc3lz L2dlb20vZ2VvbV9kaXNrLmMNCkBAIC00MDQsNiArNDA0LDEwIEBAIGdfZGlz a19zdGFydChzdHJ1Y3QgYmlvICpicCkNCiAJY2FzZSBCSU9fRkxVU0g6DQog CQlnX3RyYWNlKEdfVF9CSU8sICJnX2Rpc2tfZmx1c2hjYWNoZSglcykiLA0K IAkJICAgIGJwLT5iaW9fdG8tPm5hbWUpOw0KKwkJaWYgKGRwLT5kX2ZsYWdz ICYgRElTS0ZMQUdfV1JJVEVfVEhST1VHSCkgew0KKwkJCWVycm9yID0gMDsN CisJCQlicmVhazsNCisJCX0NCiAJCWlmICghKGRwLT5kX2ZsYWdzICYgRElT S0ZMQUdfQ0FORkxVU0hDQUNIRSkpIHsNCiAJCQllcnJvciA9IEVPUE5PVFNV UFA7DQogCQkJYnJlYWs7DQpkaWZmIC0tZ2l0IGEvc3lzL2dlb20vZ2VvbV9k aXNrLmggYi9zeXMvZ2VvbS9nZW9tX2Rpc2suaA0KaW5kZXggNWUwODFjOC4u YTUzYWEzOCAxMDA2NDQNCi0tLSBhL3N5cy9nZW9tL2dlb21fZGlzay5oDQor KysgYi9zeXMvZ2VvbS9nZW9tX2Rpc2suaA0KQEAgLTExMSw2ICsxMTEsNyBA QCBzdHJ1Y3QgZGlzayB7DQogI2RlZmluZSBESVNLRkxBR19MQUNLU19HT05F CTB4MTANCiAjZGVmaW5lIERJU0tGTEFHX1VOTUFQUEVEX0JJTwkweDIwDQog I2RlZmluZSBESVNLRkxBR19MQUNLU19ERUxNQVgJMHg0MA0KKyNkZWZpbmUg RElTS0ZMQUdfV1JJVEVfVEhST1VHSAkweDgwDQogDQogc3RydWN0IGRpc2sg KmRpc2tfYWxsb2Modm9pZCk7DQogdm9pZCBkaXNrX2NyZWF0ZShzdHJ1Y3Qg ZGlzayAqZGlzaywgaW50IHZlcnNpb24pOw0K --2628712688-239966612-1391696912=:61272--