From owner-freebsd-fs@FreeBSD.ORG Thu Feb 6 14:45:49 2014 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2D4F1AC6 for ; Thu, 6 Feb 2014 14:45:49 +0000 (UTC) Received: from krichy.tvnetwork.hu (unknown [IPv6:2a01:be00:0:2::10]) by mx1.freebsd.org (Postfix) with ESMTP id A777C1CE5 for ; Thu, 6 Feb 2014 14:45:48 +0000 (UTC) Received: by krichy.tvnetwork.hu (Postfix, from userid 1000) id 3A3054161; Thu, 6 Feb 2014 15:44:28 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by krichy.tvnetwork.hu (Postfix) with ESMTP id 316B34160; Thu, 6 Feb 2014 15:44:28 +0100 (CET) Date: Thu, 6 Feb 2014 15:44:28 +0100 (CET) From: krichy@tvnetwork.hu To: Richard Kojedzinszky Subject: Re: geom write cache handling In-Reply-To: Message-ID: References: User-Agent: Alpine 2.10 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1030603365-1547680064-1391697868=:18231" Cc: freebsd-fs@freebsd.org 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:45:49 -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. --1030603365-1547680064-1391697868=:18231 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Fortunately I have my drives attached to a SAS controller, so I could add quirks for them. They are also attached. Regards, Kojedzinszky Richard Euronet Magyarorszag Informatika Zrt. On Thu, 6 Feb 2014, Richard Kojedzinszky wrote: > Date: Thu, 6 Feb 2014 15:36:54 +0100 (CET) > From: Richard Kojedzinszky > To: freebsd-fs@freebsd.org > Subject: geom write cache handling > > 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 --1030603365-1547680064-1391697868=:18231 Content-Type: TEXT/x-diff; name=s3700.patch Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename=s3700.patch Y29tbWl0IDA4NDFhYzFjZjM1Mzk3MTgxZGI5OGRmOTU0MDE1NDA5NzM1ZjFm YzQNCkF1dGhvcjogQ2hhcmxpZSBSb290IDxyb290QHBpLm5tZHBzLm5ldD4N CkRhdGU6ICAgVGh1IEZlYiA2IDE0OjQyOjIwIDIwMTQgKzAxMDANCg0KICAg IEludGVsIFMzNzAwIFNTRCBxdWlya3MNCg0KZGlmZiAtLWdpdCBhL3N5cy9j YW0vc2NzaS9zY3NpX2RhLmMgYi9zeXMvY2FtL3Njc2kvc2NzaV9kYS5jDQpp bmRleCBjYjVkNDFmLi45M2JiMjMxIDEwMDY0NA0KLS0tIGEvc3lzL2NhbS9z Y3NpL3Njc2lfZGEuYw0KKysrIGIvc3lzL2NhbS9zY3NpL3Njc2lfZGEuYw0K QEAgLTk4NCw2ICs5ODQsMTUgQEAgc3RhdGljIHN0cnVjdCBkYV9xdWlya19l bnRyeSBkYV9xdWlya190YWJsZVtdID0NCiAJfSwNCiAJew0KIAkJLyoNCisJ CSAqIEludGVsIFMzNzAwIFNlcmllcyBTU0RzDQorCQkgKiA0ayBvcHRpbWlz ZWQgJiB0cmltIG9ubHkgd29ya3MgaW4gNGsgcmVxdWVzdHMgKyA0ayBhbGln bmVkDQorCQkgKiBjYWNoZSBmbHVzaCBub3QgbmVlZGVkLCBhcyBwb3dlci1s b3NzLXByb3RlY3RlZA0KKwkJICovDQorCQl7IFRfRElSRUNULCBTSVBfTUVE SUFfRklYRUQsICJBVEEiLCAiSU5URUwgU1NEU0MyQkEqIiwgIioiIH0sDQor CQkvKnF1aXJrcyovREFfUV80SyB8IERBX1FfTk9fU1lOQ19DQUNIRQ0KKwl9 LA0KKwl7DQorCQkvKg0KIAkJICogS2luZ3N0b24gRTEwMCBTZXJpZXMgU1NE cw0KIAkJICogNGsgb3B0aW1pc2VkICYgdHJpbSBvbmx5IHdvcmtzIGluIDRr IHJlcXVlc3RzICsgNGsgYWxpZ25lZA0KIAkJICovDQo= --1030603365-1547680064-1391697868=:18231 Content-Type: TEXT/x-diff; name=stec.patch Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename=stec.patch Y29tbWl0IDcxNmNjZjBiMDMwNTA0ZTM5YWM2MGMyNGIxYWFlZDkxOTliZTEx M2YNCkF1dGhvcjogQ2hhcmxpZSBSb290IDxyb290QHBpLm5tZHBzLm5ldD4N CkRhdGU6ICAgV2VkIEphbiAxNSAyMTo1MDo0NCAyMDE0ICswMTAwDQoNCiAg ICBBZGRlZCBubyBzeW5jIGNhY2hlIHF1aXJrIGZvciBTVEVDIE1BQ0gxNiBk cml2ZXMNCg0KZGlmZiAtLWdpdCBhL3N5cy9jYW0vc2NzaS9zY3NpX2RhLmMg Yi9zeXMvY2FtL3Njc2kvc2NzaV9kYS5jDQppbmRleCA0YTk2OTgxLi5jYjVk NDFmIDEwMDY0NA0KLS0tIGEvc3lzL2NhbS9zY3NpL3Njc2lfZGEuYw0KKysr IGIvc3lzL2NhbS9zY3NpL3Njc2lfZGEuYw0KQEAgLTEwNjIsNiArMTA2Miwx NCBAQCBzdGF0aWMgc3RydWN0IGRhX3F1aXJrX2VudHJ5IGRhX3F1aXJrX3Rh YmxlW10gPQ0KIAkJeyBUX0RJUkVDVCwgU0lQX01FRElBX0ZJWEVELCAiQVRB IiwgIlNHOVhDUzJEKiIsICIqIiB9LA0KIAkJLypxdWlya3MqL0RBX1FfNEsN CiAJfSwNCisJew0KKwkJLyoNCisJCSAqIFNURUMgTUFDSDE2IFNBVEEgU1NE cw0KKwkJICogTm8gY2FjaGUgc3luYw0KKwkJICovDQorCQl7IFRfRElSRUNU LCBTSVBfTUVESUFfRklYRUQsICJBVEEiLCAiU1RFQyAgICBNQUNIMTYqIiwg IioiIH0sDQorCQkvKnF1aXJrcyovREFfUV9OT19TWU5DX0NBQ0hFDQorCX0s DQogfTsNCiANCiBzdGF0aWMJZGlza19zdHJhdGVneV90CWRhc3RyYXRlZ3k7 DQo= --1030603365-1547680064-1391697868=:18231--