From owner-freebsd-scsi@FreeBSD.ORG Mon Jul 23 11:07:24 2012 Return-Path: Delivered-To: freebsd-scsi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BAB521065670 for ; Mon, 23 Jul 2012 11:07:24 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id A3F608FC1B for ; Mon, 23 Jul 2012 11:07:24 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q6NB7OP8090143 for ; Mon, 23 Jul 2012 11:07:24 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q6NB7OBg090141 for freebsd-scsi@FreeBSD.org; Mon, 23 Jul 2012 11:07:24 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 23 Jul 2012 11:07:24 GMT Message-Id: <201207231107.q6NB7OBg090141@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-scsi@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-scsi@FreeBSD.org X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2012 11:07:24 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/169976 scsi [cam] [patch] make scsi_da use sysctl values where app o kern/169974 scsi [cam] [patch] add Quirks for SSD that are 4k optimised o kern/169835 scsi [patch] remove some unused variables from scsi_da prob o kern/169801 scsi [cam] [patc] make changes to delete_method in scsi_da o kern/169403 scsi [cam] [patch] CAM layer, I/O starvation, no fairness o kern/165982 scsi [mpt] mpt instability, drive resets, and losses on Fre o kern/165740 scsi [cam] SCSI code must drain callbacks before free o kern/163713 scsi [aic7xxx] [patch] Add Adaptec29329LPE to aic79xx_pci.c o kern/162256 scsi [mpt] QUEUE FULL EVENT and 'mpt_cam_event: 0x0' o kern/161809 scsi [cam] [patch] set kern.cam.boot_delay via build option o kern/159412 scsi [ciss] 7.3 RELEASE: ciss0 ADAPTER HEARTBEAT FAILED err o kern/157770 scsi [iscsi] [panic] iscsi_initiator panic o kern/154432 scsi [xpt] run_interrupt_driven_hooks: still waiting after o kern/153514 scsi [cam] [panic] CAM related panic o kern/153361 scsi [ciss] Smart Array 5300 boot/detect drive problem o kern/152250 scsi [ciss] [patch] Kernel panic when hw.ciss.expose_hidden o kern/151564 scsi [ciss] ciss(4) should increase CISS_MAX_LOGICAL to 10 o docs/151336 scsi Missing documentation of scsi_ and ata_ functions in c s kern/149927 scsi [cam] hard drive not stopped before removing power dur o kern/148083 scsi [aac] Strange device reporting o kern/147704 scsi [mpt] sys/dev/mpt: new chip revision, partially unsupp o kern/146287 scsi [ciss] ciss(4) cannot see more than one SmartArray con o kern/145768 scsi [mpt] can't perform I/O on SAS based SAN disk in freeb o kern/144648 scsi [aac] Strange values of speed and bus width in dmesg o kern/144301 scsi [ciss] [hang] HP proliant server locks when using ciss o kern/142351 scsi [mpt] LSILogic driver performance problems o kern/134488 scsi [mpt] MPT SCSI driver probes max. 8 LUNs per device o kern/132250 scsi [ciss] ciss driver does not support more then 15 drive o kern/132206 scsi [mpt] system panics on boot when mirroring and 2nd dri o kern/130621 scsi [mpt] tranfer rate is inscrutable slow when use lsi213 o kern/129602 scsi [ahd] ahd(4) gets confused and wedges SCSI bus o kern/128452 scsi [sa] [panic] Accessing SCSI tape drive randomly crashe o kern/128245 scsi [scsi] "inquiry data fails comparison at DV1 step" [re o kern/127927 scsi [isp] isp(4) target driver crashes kernel when set up o kern/127717 scsi [ata] [patch] [request] - support write cache toggling o kern/123674 scsi [ahc] ahc driver dumping o kern/123520 scsi [ahd] unable to boot from net while using ahd o sparc/121676 scsi [iscsi] iscontrol do not connect iscsi-target on sparc o kern/120487 scsi [sg] scsi_sg incompatible with scanners o kern/120247 scsi [mpt] FreeBSD 6.3 and LSI Logic 1030 = only 3.300MB/s o kern/114597 scsi [sym] System hangs at SCSI bus reset with dual HBAs o kern/110847 scsi [ahd] Tyan U320 onboard problem with more than 3 disks o kern/99954 scsi [ahc] reading from DVD failes on 6.x [regression] o kern/92798 scsi [ahc] SCSI problem with timeouts o kern/90282 scsi [sym] SCSI bus resets cause loss of ch device o kern/76178 scsi [ahd] Problem with ahd and large SCSI Raid system o kern/74627 scsi [ahc] [hang] Adaptec 2940U2W Can't boot 5.3 s kern/61165 scsi [panic] kernel page fault after calling cam_send_ccb o kern/60641 scsi [sym] Sporadic SCSI bus resets with 53C810 under load o kern/60598 scsi wire down of scsi devices conflicts with config s kern/57398 scsi [mly] Current fails to install on mly(4) based RAID di o kern/52638 scsi [panic] SCSI U320 on SMP server won't run faster than o kern/44587 scsi dev/dpt/dpt.h is missing defines required for DPT_HAND o kern/39388 scsi ncr/sym drivers fail with 53c810 and more than 256MB m o kern/35234 scsi World access to /dev/pass? (for scanner) requires acce 55 problems total. From owner-freebsd-scsi@FreeBSD.ORG Mon Jul 23 13:42:23 2012 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 40A771065670; Mon, 23 Jul 2012 13:42:23 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by mx1.freebsd.org (Postfix) with ESMTP id 3C97D8FC14; Mon, 23 Jul 2012 13:42:22 +0000 (UTC) Received: by wibhr14 with SMTP id hr14so2246744wib.13 for ; Mon, 23 Jul 2012 06:42:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :content-type:content-transfer-encoding; bh=jpL8eX87fMDnT61oa1GqO3ite0JXyaW/GBtmyEvjjyg=; b=somsjU+1qNxZW7SeEucsI18I6LDI9KCYrrYTgh/VyRBylI6U/hFKRA49SZjmoTng3b Byp23WK7V5BJvRKxUvSc6v98fveoj8n60uE9mXtc5QC9RwkIt7mBb2Y9PYrIdMfWRKqO USDxUD+DEgPIR0Reze/4b0IsOUuaOEH+jnVjNbQWT4/RmeY0AJof6HjOD3ujkWn6pHe0 JxaNUjQOxS9L9AZxZyBjoUWODQbopsaqehQFL1MmyS//HlW3Fs09d6xWMJiNGcgII9l6 UgLYGdXyj0a4jjXjzmjMEbAiPC/D6OBZw1Oop0pDS7OPGX8dGDnsgQQrxJ3xm7MxWpfG dQaQ== Received: by 10.216.238.30 with SMTP id z30mr8251090weq.223.1343050941198; Mon, 23 Jul 2012 06:42:21 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id fu8sm17010637wib.5.2012.07.23.06.42.19 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 23 Jul 2012 06:42:20 -0700 (PDT) Sender: Alexander Motin Message-ID: <500D54B9.1010800@FreeBSD.org> Date: Mon, 23 Jul 2012 16:42:17 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120628 Thunderbird/13.0.1 MIME-Version: 1.0 To: freebsd-scsi@freebsd.org, freebsd-geom@FreeBSD.org Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: Kris Moore Subject: [RFC] CAM/GEOM media change notification X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2012 13:42:23 -0000 Hi. On PC-BSD developers request and sponsored by iXsystems, Inc, I've made patch for present FreeBSD 10-CURRENT implementing media change notification for DA and CD removable media devices, that I would like to be reviewed and tested. It includes three parts: 1) Modifications to CAM to detect media media changes and report them to disk(9) layer. For modern SATA (and potentially UAS) devices it utilizes Asynchronous Notification mechanism to receive events from hardware. Active polling with TEST UNIT READY commands with 3 seconds period is used for incapable hardware. After that both CD and DA drivers work the same way, detecting two conditions: "NOT READY: Medium not present" after medium was detected previously, and "UNIT ATTENTION: Not ready to ready change, medium may have changed". First one reported to disk(9) as media removal, second as media insert/change. To reliably receive second event new AC_UNIT_ATTENTION async added to make UAs broadcasted to all periphs by generic error handling code. 2) Modifications to GEOM core to handle media remove and change events. Media removal handled by spoiling all consumers attached to the provider. Media change event also schedules provider retaste after spoiling to probe new media. New flag G_CF_ORPHAN was added to consumers to reflect that consumer is in process of destruction. It allows retaste to create new geom instance of the same class, while previous one is still dying. 3) Modifications to several major GEOM classes: DEV -- to report media change events to devd; VFS -- to handle spoiling same as orphan to prevent accessing replaced media. PART class already handles spoiling alike to orphan. As result, such events are reported to devd for USB card reader: - on media inserted: !system=DEVFS subsystem=CDEV type=MEDIACHANGE cdev=da3 !system=DEVFS subsystem=CDEV type=CREATE cdev=da3s1 !system=DEVFS subsystem=CDEV type=CREATE cdev=msdosfs/NIKON D7000 - on media removed: !system=DEVFS subsystem=CDEV type=DESTROY cdev=da3s1 !system=DEVFS subsystem=CDEV type=DESTROY cdev=msdosfs/NIKON D7000 Patch can be found here: http://people.freebsd.org/~mav/mediachange8.patch Any comments/objections/propositions? -- Alexander Motin From owner-freebsd-scsi@FreeBSD.ORG Tue Jul 24 07:49:38 2012 Return-Path: Delivered-To: freebsd-scsi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CAED8106566B; Tue, 24 Jul 2012 07:49:38 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id B6E878FC15; Tue, 24 Jul 2012 07:49:37 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id KAA00257; Tue, 24 Jul 2012 10:49:36 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1StZs7-0004BY-LC; Tue, 24 Jul 2012 10:49:35 +0300 Message-ID: <500E538E.1060908@FreeBSD.org> Date: Tue, 24 Jul 2012 10:49:34 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120620 Thunderbird/13.0.1 MIME-Version: 1.0 To: Alexander Motin References: <500D54B9.1010800@FreeBSD.org> In-Reply-To: <500D54B9.1010800@FreeBSD.org> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: freebsd-scsi@FreeBSD.org, freebsd-geom@FreeBSD.org Subject: Re: [RFC] CAM/GEOM media change notification X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 07:49:38 -0000 on 23/07/2012 16:42 Alexander Motin said the following: > Patch can be found here: > http://people.freebsd.org/~mav/mediachange8.patch > > Any comments/objections/propositions? Alexander, would it make sense for scsi_cd to also use GET EVENT STATUS NOTIFICATION command (4A) with Polled flag and Media bit set in Notification Class in addition to TUR for devices that do not support asynchronous notification? I think that this should increase reliability of detecting CD media changes between polls. -- Andriy Gapon From owner-freebsd-scsi@FreeBSD.ORG Wed Jul 25 20:27:53 2012 Return-Path: Delivered-To: freebsd-scsi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9B709106566B; Wed, 25 Jul 2012 20:27:53 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 56EB68FC14; Wed, 25 Jul 2012 20:27:52 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id XAA22830; Wed, 25 Jul 2012 23:27:50 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Su8BS-000934-4E; Wed, 25 Jul 2012 23:27:50 +0300 Message-ID: <501056C4.3080806@FreeBSD.org> Date: Wed, 25 Jul 2012 23:27:48 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120620 Thunderbird/13.0.1 MIME-Version: 1.0 To: freebsd-scsi@FreeBSD.org, freebsd-geom@FreeBSD.org X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=X-VIET-VPS Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org Subject: geom <-> cam disk X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 20:27:53 -0000 Preamble. I am trying to understand in detail how things work at GEOM <-> "CAM disk" boundary. I am looking at scsi_da and ata_da which seem to be twins in this respect. I got an impression that the bioq_disksort calls in the strategy methods and the related queues are completely useless in the GEOM single-threaded world. There is only one thread, g_down, that can call a strategy method, the method enqueues a bio, then calls a schedule function and through xpt_schedule the call flow continues to a start method which dequeues the bio and off it goes. I currently can see how a bio queue can accumulate more than one bio. What am I missing? :-) I will be very glad to learn more about this layer if anyone is willing to educate me. Thank you in advance. P.S. I wrote a very simple to DTrace script to my "theory" experimentally and my testing with various workloads didn't disprove the theory so far (which doesn't mean that it is correct, of course). The script: fbt::bioq_disksort:entry /args[0]->queue.tqh_first == 0/ { @["empty"] = count(); } fbt::bioq_disksort:entry /args[0]->queue.tqh_first != 0/ { @["non-empty"] = count(); } It works on all bioq_disksort calls, but I stressing only ada disks at the moment. -- Andriy Gapon From owner-freebsd-scsi@FreeBSD.ORG Wed Jul 25 21:14:11 2012 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9711E106564A; Wed, 25 Jul 2012 21:14:11 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 48FB28FC0A; Wed, 25 Jul 2012 21:14:11 +0000 (UTC) Received: from [127.0.0.1] (pooker.samsco.org [168.103.85.57]) (authenticated bits=0) by pooker.samsco.org (8.14.5/8.14.5) with ESMTP id q6PLE2bT012334; Wed, 25 Jul 2012 15:14:03 -0600 (MDT) (envelope-from scottl@samsco.org) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Scott Long In-Reply-To: <501056C4.3080806@FreeBSD.org> Date: Wed, 25 Jul 2012 14:14:02 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <23011628-17F1-49A0-A41E-E7A8A8E3EA64@samsco.org> References: <501056C4.3080806@FreeBSD.org> To: Andriy Gapon X-Mailer: Apple Mail (2.1278) X-Spam-Status: No, score=-50.0 required=3.8 tests=ALL_TRUSTED, T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on pooker.samsco.org Cc: freebsd-scsi@freebsd.org, freebsd-hackers@freebsd.org, freebsd-geom@freebsd.org Subject: Re: geom <-> cam disk X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 21:14:11 -0000 Once the bio is put into the bioq from da_strategy, the CAM scheduler is = called. It may or may not wind up calling dastart right away; if the = simq or devq is frozen, or if the devq has been exhausted, then the io = will be deferred until later and the call stack will unwind back into = g_down. The bioq can therefore accumulate many bio's before being = drained. Draining will usually happen from the camisr, at which point = you can potentially have i/o being initiated from both the camisr and = the g_down threads in parallel. The monolithic locking in CAM right now = prevents this from actually happening, though that's a topic that needs = to be revisited. Scott On Jul 25, 2012, at 1:27 PM, Andriy Gapon wrote: >=20 >=20 > Preamble. I am trying to understand in detail how things work at GEOM = <-> "CAM > disk" boundary. I am looking at scsi_da and ata_da which seem to be = twins in > this respect. >=20 > I got an impression that the bioq_disksort calls in the strategy = methods and the > related queues are completely useless in the GEOM single-threaded = world. > There is only one thread, g_down, that can call a strategy method, the = method > enqueues a bio, then calls a schedule function and through = xpt_schedule the call > flow continues to a start method which dequeues the bio and off it = goes. > I currently can see how a bio queue can accumulate more than one bio. >=20 > What am I missing? :-) > I will be very glad to learn more about this layer if anyone is = willing to > educate me. > Thank you in advance. >=20 > P.S. I wrote a very simple to DTrace script to my "theory" = experimentally and my > testing with various workloads didn't disprove the theory so far = (which doesn't > mean that it is correct, of course). >=20 > The script: > fbt::bioq_disksort:entry > /args[0]->queue.tqh_first =3D=3D 0/ > { > @["empty"] =3D count(); > } >=20 > fbt::bioq_disksort:entry > /args[0]->queue.tqh_first !=3D 0/ > { > @["non-empty"] =3D count(); > } >=20 > It works on all bioq_disksort calls, but I stressing only ada disks at = the moment. > --=20 > Andriy Gapon >=20 From owner-freebsd-scsi@FreeBSD.ORG Wed Jul 25 22:07:20 2012 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 28E09106564A; Wed, 25 Jul 2012 22:07:20 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 36DE48FC0C; Wed, 25 Jul 2012 22:07:19 +0000 (UTC) Received: by wgbds11 with SMTP id ds11so1164488wgb.31 for ; Wed, 25 Jul 2012 15:07:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=xCjRclWupUBbHNW28bshcuJldym+nph0RS8wi0HH9UM=; b=ULFogl4bT0/BjFx1VnUjvWWa1w2ihMH21rpgcF331r7/H7Q1PlCqQZ2elhO8yZYauG j9VsRMyoFL8ixWtPDTk/FF8mG8mwSZV2b0C/uiz0d/xXlKdBzoppGZT9ZrI5u5xtuSbB EYeyvurVb/Z9ESA7plDv5aITI8s54fvIdPx64vs+e47a3oQ9sj0bcoroKIY4dN9zs78n uZH2VHKpiSeTxIWk2mYUSR7qu8UC9Vv2wYlCbn9ftOHvNL6dRnrWGWLHDKJUkE08MVtJ ZuyyIVOo1mFyxy6ObaFiiyKC2EQT7EEYe3uQwVhPv7Hk0CdtzMvSw7m1vDkzOPe91x7t 1kKA== Received: by 10.180.78.4 with SMTP id x4mr8035938wiw.19.1343254038100; Wed, 25 Jul 2012 15:07:18 -0700 (PDT) Received: from pc.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id bc2sm7301435wib.0.2012.07.25.15.07.16 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 25 Jul 2012 15:07:17 -0700 (PDT) Sender: Alexander Motin Message-ID: <50106E5F.4030402@FreeBSD.org> Date: Thu, 26 Jul 2012 01:08:31 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120621 Thunderbird/13.0.1 MIME-Version: 1.0 To: Andriy Gapon References: <501056C4.3080806@FreeBSD.org> In-Reply-To: <501056C4.3080806@FreeBSD.org> Content-Type: text/plain; charset=x-viet-vps; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-scsi@FreeBSD.org, freebsd-hackers@FreeBSD.org, freebsd-geom@FreeBSD.org Subject: Re: geom <-> cam disk X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 22:07:20 -0000 On 25.07.2012 23:27, Andriy Gapon wrote: > Preamble. I am trying to understand in detail how things work at GEOM <-> "CAM > disk" boundary. I am looking at scsi_da and ata_da which seem to be twins in > this respect. > > I got an impression that the bioq_disksort calls in the strategy methods and the > related queues are completely useless in the GEOM single-threaded world. > There is only one thread, g_down, that can call a strategy method, the method > enqueues a bio, then calls a schedule function and through xpt_schedule the call > flow continues to a start method which dequeues the bio and off it goes. > I currently can see how a bio queue can accumulate more than one bio. > > What am I missing? :-) > I will be very glad to learn more about this layer if anyone is willing to > educate me. > Thank you in advance. > > P.S. I wrote a very simple to DTrace script to my "theory" experimentally and my > testing with various workloads didn't disprove the theory so far (which doesn't > mean that it is correct, of course). > > The script: > fbt::bioq_disksort:entry > /args[0]->queue.tqh_first == 0/ > { > @["empty"] = count(); > } > > fbt::bioq_disksort:entry > /args[0]->queue.tqh_first != 0/ > { > @["non-empty"] = count(); > } > > It works on all bioq_disksort calls, but I stressing only ada disks at the moment. Different controllers have different command queueing limitations. If you are testing with ahci(4) driver and modern disks, then their 32 command slots per port can be enough for many workloads to enqueue all commands to the hardware and leave queue empty as you've described. But if you take harder workload, or controller/ device without command queueing support, extra requests will be accumulated on that bioq and sorted there. -- Alexander Motin From owner-freebsd-scsi@FreeBSD.ORG Wed Jul 25 22:30:16 2012 Return-Path: Delivered-To: freebsd-scsi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A4B92106566B; Wed, 25 Jul 2012 22:30:16 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 7206D8FC14; Wed, 25 Jul 2012 22:30:15 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id BAA24285; Thu, 26 Jul 2012 01:29:57 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1SuA5d-0009BM-28; Thu, 26 Jul 2012 01:29:57 +0300 Message-ID: <50107362.7050709@FreeBSD.org> Date: Thu, 26 Jul 2012 01:29:54 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120620 Thunderbird/13.0.1 MIME-Version: 1.0 To: Scott Long References: <501056C4.3080806@FreeBSD.org> <23011628-17F1-49A0-A41E-E7A8A8E3EA64@samsco.org> In-Reply-To: <23011628-17F1-49A0-A41E-E7A8A8E3EA64@samsco.org> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-scsi@FreeBSD.org, freebsd-hackers@FreeBSD.org, freebsd-geom@FreeBSD.org Subject: Re: geom <-> cam disk X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 22:30:16 -0000 on 26/07/2012 00:14 Scott Long said the following: > Once the bio is put into the bioq from da_strategy, the CAM scheduler is > called. It may or may not wind up calling dastart right away; if the simq or > devq is frozen, or if the devq has been exhausted, then the io will be > deferred until later and the call stack will unwind back into g_down. The > bioq can therefore accumulate many bio's before being drained. Draining will > usually happen from the camisr, at which point you can potentially have i/o > being initiated from both the camisr and the g_down threads in parallel. The Uh-hah. Thank you for the answer. I didn't think of the case of frozen/exhausted queues and also didn't hit in my tests. Now I am starting to understand the logic in xpt_run_dev_allocq. BTW, I think that it would be nice if the GEOM work-processing could re-use the CAM model. That is, try to execute GEOM bio transformations in the original thread as much as possible, defer work to the GEOM thread as the last resort. > monolithic locking in CAM right now prevents this from actually happening, > though that's a topic that needs to be revisited. > On Jul 25, 2012, at 1:27 PM, Andriy Gapon wrote: > >> >> >> Preamble. I am trying to understand in detail how things work at GEOM <-> >> "CAM disk" boundary. I am looking at scsi_da and ata_da which seem to be >> twins in this respect. >> >> I got an impression that the bioq_disksort calls in the strategy methods >> and the related queues are completely useless in the GEOM single-threaded >> world. There is only one thread, g_down, that can call a strategy method, >> the method enqueues a bio, then calls a schedule function and through >> xpt_schedule the call flow continues to a start method which dequeues the >> bio and off it goes. I currently can see how a bio queue can accumulate >> more than one bio. >> >> What am I missing? :-) I will be very glad to learn more about this layer >> if anyone is willing to educate me. Thank you in advance. >> >> P.S. I wrote a very simple to DTrace script to my "theory" experimentally >> and my testing with various workloads didn't disprove the theory so far >> (which doesn't mean that it is correct, of course). >> >> The script: fbt::bioq_disksort:entry /args[0]->queue.tqh_first == 0/ { >> @["empty"] = count(); } >> >> fbt::bioq_disksort:entry /args[0]->queue.tqh_first != 0/ { @["non-empty"] = >> count(); } >> >> It works on all bioq_disksort calls, but I stressing only ada disks at the >> moment. -- Andriy Gapon >> > -- Andriy Gapon From owner-freebsd-scsi@FreeBSD.ORG Wed Jul 25 22:36:24 2012 Return-Path: Delivered-To: freebsd-scsi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0E520106564A; Wed, 25 Jul 2012 22:36:24 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id C4C7D8FC15; Wed, 25 Jul 2012 22:36:22 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id BAA24384; Thu, 26 Jul 2012 01:36:21 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1SuABp-0009Bn-9I; Thu, 26 Jul 2012 01:36:21 +0300 Message-ID: <501074E4.4040805@FreeBSD.org> Date: Thu, 26 Jul 2012 01:36:20 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120620 Thunderbird/13.0.1 MIME-Version: 1.0 To: Alexander Motin References: <501056C4.3080806@FreeBSD.org> <50106E5F.4030402@FreeBSD.org> In-Reply-To: <50106E5F.4030402@FreeBSD.org> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=x-viet-vps Content-Transfer-Encoding: 7bit Cc: freebsd-scsi@FreeBSD.org, freebsd-hackers@FreeBSD.org, freebsd-geom@FreeBSD.org Subject: Re: geom <-> cam disk X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 22:36:24 -0000 on 26/07/2012 01:08 Alexander Motin said the following: > Different controllers have different command queueing limitations. If you are > testing with ahci(4) driver and modern disks, then their 32 command slots per > port can be enough for many workloads to enqueue all commands to the hardware > and leave queue empty as you've described. But if you take harder workload, or > controller/ device without command queueing support, extra requests will be > accumulated on that bioq and sorted there. Alexander, thank you for the reply. Indeed, using 64 parallel dd processes with bs=512 I was able to 'kick in' the disksort logic. But I am not sure if the disksort algorithm makes much difference in this case given the number of commands that a disk firmware can internally re-order. (Not mentioning that potentially disksort could starve some I/O bound processes in favor of others -- but that's a totally different topic). But then, of course, for the less capable hardware the disksort could still be a significant factor. -- Andriy Gapon From owner-freebsd-scsi@FreeBSD.ORG Wed Jul 25 22:40:14 2012 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9A92A106566C for ; Wed, 25 Jul 2012 22:40:14 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 54B7D8FC14 for ; Wed, 25 Jul 2012 22:40:14 +0000 (UTC) Received: by obbun3 with SMTP id un3so2219238obb.13 for ; Wed, 25 Jul 2012 15:40:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=/OhSNf3qOl1/rBiaOGT2DJtTfoLyvlsMZS2FF/XjMgQ=; b=aHbiqGn2kAc/bEpYPmZF4V76SRx2CAHYSuIlTKAmh3sE4qaPTO0Xkc9xY4uWmw+I+Q 7sFGt4RLKF6lgFglfs340ntdjt6tK+XtyytRvLoZPX6afSSu41FqARkZMbCBMqfK6O3L thJ+RlQHJikGLvut0QjPtwGf/O66roNgTn0OLjhoKbSgY3XRl5ss5960RcWwkiZwiBTR Fr+YgMR5s8O0ooBNUfF3+z5I0mtx3cHXUC153TdwIryQXboLBqgpoSKkcqVV8z5FxajC FPUNU+IQ1fejFS/c+0QUHHQcGuYlP1448yTe67+nu4Efpqk2elUZDrMGy3O3aF7m+8RZ ufAw== Received: by 10.182.1.72 with SMTP id 8mr38145263obk.61.1343256013961; Wed, 25 Jul 2012 15:40:13 -0700 (PDT) Received: from [10.30.101.53] ([209.117.142.2]) by mx.google.com with ESMTPS id hd10sm16944801obc.8.2012.07.25.15.40.12 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 25 Jul 2012 15:40:13 -0700 (PDT) Sender: Warner Losh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <50107362.7050709@FreeBSD.org> Date: Wed, 25 Jul 2012 16:40:10 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <6BF84E40-8B71-4AFD-B457-5B3299BD4F92@bsdimp.com> References: <501056C4.3080806@FreeBSD.org> <23011628-17F1-49A0-A41E-E7A8A8E3EA64@samsco.org> <50107362.7050709@FreeBSD.org> To: Andriy Gapon X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQntebkclwuG9q8Wrbh2eh8AeD8maZNXwf1cOOjtKkq5JVVwfcRnxOoJwepjr57K1WSF8Hk0 Cc: freebsd-scsi@FreeBSD.org, Scott Long , freebsd-geom@FreeBSD.org, freebsd-hackers@FreeBSD.org Subject: Re: geom <-> cam disk X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 22:40:14 -0000 On Jul 25, 2012, at 4:29 PM, Andriy Gapon wrote: > BTW, I think that it would be nice if the GEOM work-processing could = re-use the > CAM model. > That is, try to execute GEOM bio transformations in the original = thread as much > as possible, defer work to the GEOM thread as the last resort. Lots of people would like to see this. Especially people that want high = iops. Warner From owner-freebsd-scsi@FreeBSD.ORG Wed Jul 25 23:47:11 2012 Return-Path: Delivered-To: freebsd-scsi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2C1AF106566B; Wed, 25 Jul 2012 23:47:11 +0000 (UTC) (envelope-from prvs=1553f1cdfa=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id F0C9C8FC14; Wed, 25 Jul 2012 23:47:09 +0000 (UTC) X-Spam-Processed: mail1.multiplay.co.uk, Thu, 26 Jul 2012 00:46:04 +0100 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-5.0 required=6.0 tests=USER_IN_WHITELIST shortcircuit=ham autolearn=disabled version=3.2.5 Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50020941215.msg; Thu, 26 Jul 2012 00:46:04 +0100 X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=1553f1cdfa=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: <91A8B33A32B546BB82F0A1CFF4D1F4BD@multiplay.co.uk> From: "Steven Hartland" To: "Andriy Gapon" , "Alexander Motin" References: <501056C4.3080806@FreeBSD.org> <50106E5F.4030402@FreeBSD.org> <501074E4.4040805@FreeBSD.org> Date: Thu, 26 Jul 2012 00:46:11 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: freebsd-scsi@FreeBSD.org, freebsd-geom@FreeBSD.org, freebsd-hackers@FreeBSD.org Subject: Re: geom <-> cam disk X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 23:47:11 -0000 ----- Original Message ----- From: "Andriy Gapon" > on 26/07/2012 01:08 Alexander Motin said the following: >> Different controllers have different command queueing limitations. If you are >> testing with ahci(4) driver and modern disks, then their 32 command slots per >> port can be enough for many workloads to enqueue all commands to the hardware >> and leave queue empty as you've described. But if you take harder workload, or >> controller/ device without command queueing support, extra requests will be >> accumulated on that bioq and sorted there. > > Alexander, > > thank you for the reply. > Indeed, using 64 parallel dd processes with bs=512 I was able to 'kick in' the > disksort logic. But I am not sure if the disksort algorithm makes much > difference in this case given the number of commands that a disk firmware can > internally re-order. (Not mentioning that potentially disksort could starve > some I/O bound processes in favor of others -- but that's a totally different > topic). > > But then, of course, for the less capable hardware the disksort could still be a > significant factor. The sort is actually important for delete requests too as this can allow the delete processing code to operate more effectively which can result in significant performance increases if this then allows request combining. For example Alexander is currently reviewing some changes I've written to the delete processing which include an optimisation that increases SSD delete performance from ~630MB/s to 1.3GB/s on 3rd gen sandforce controllers. Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-scsi@FreeBSD.ORG Thu Jul 26 22:51:29 2012 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7F137106566B; Thu, 26 Jul 2012 22:51:29 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id A4BA18FC0A; Thu, 26 Jul 2012 22:51:28 +0000 (UTC) Received: by weyx56 with SMTP id x56so2016213wey.13 for ; Thu, 26 Jul 2012 15:51:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=rAynNnU22iw2u5EvdLxw9krmd6gtanSKpGevtGoOrR0=; b=tG0Qz1F35nqqiph5jbw9JiW4rF5OtsI4l6kHjQInB3B6y9+6Ud/+QgF8LMHjLXrBIN l6FfC8gpr34zUlpJKtLbIbsx9RYr6NvBEoAvPph5v7klIVvoE7T1H5M+Iuo3JfkV+tdS a/yfWXk8Qexa6zq4KFWMCrBiSYBpk+mCkjYlJv1eE62ly2UJL6IAwiIXz8GAOwj0evXr h5qU8wdHNvKdH1hdWSo5b1e7nAvfhLV0F9Sdxy1OQeSJpbq2Lb8L5rAcAF1kxN+v6gif +JQ7EDvMhVwgKD4x9sVAPtfqPsj92U8gumZ+YLd+3uMfz/gBE+5yFE/iZ3nhiA63PmUb jZfg== Received: by 10.180.103.136 with SMTP id fw8mr902199wib.20.1343343087544; Thu, 26 Jul 2012 15:51:27 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id el6sm10666830wib.8.2012.07.26.15.51.25 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 26 Jul 2012 15:51:26 -0700 (PDT) Sender: Alexander Motin Message-ID: <5011C9EC.5080008@FreeBSD.org> Date: Fri, 27 Jul 2012 01:51:24 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120628 Thunderbird/13.0.1 MIME-Version: 1.0 To: Andriy Gapon References: <500D54B9.1010800@FreeBSD.org> <500E538E.1060908@FreeBSD.org> In-Reply-To: <500E538E.1060908@FreeBSD.org> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-scsi@FreeBSD.org, freebsd-geom@FreeBSD.org Subject: Re: [RFC] CAM/GEOM media change notification X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 22:51:29 -0000 On 24.07.2012 10:49, Andriy Gapon wrote: > on 23/07/2012 16:42 Alexander Motin said the following: >> Patch can be found here: >> http://people.freebsd.org/~mav/mediachange8.patch >> >> Any comments/objections/propositions? > > Alexander, > > would it make sense for scsi_cd to also use GET EVENT STATUS NOTIFICATION > command (4A) with Polled flag and Media bit set in Notification Class in > addition to TUR for devices that do not support asynchronous notification? > > I think that this should increase reliability of detecting CD media changes > between polls. Thanks for the hint. I've read about that command, but haven't found it useful. If media was quickly removed and reinserted and we missed it, then device will send us UNIT ATTENTION on first following request, which we will handle. If media was quickly inserted and removed and we missed it, then we just have nothing to do about it. It could be interesting to use GET EVENT STATUS NOTIFICATION in asynchronous mode to avoid polling, but it works only for queued commands, which are not supported by ATAPI devices. -- Alexander Motin From owner-freebsd-scsi@FreeBSD.ORG Fri Jul 27 09:20:08 2012 Return-Path: Delivered-To: freebsd-scsi@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B1E27106567C for ; Fri, 27 Jul 2012 09:20:08 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 9C0F48FC1C for ; Fri, 27 Jul 2012 09:20:08 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q6R9K8fN016184 for ; Fri, 27 Jul 2012 09:20:08 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q6R9K8N8016183; Fri, 27 Jul 2012 09:20:08 GMT (envelope-from gnats) Date: Fri, 27 Jul 2012 09:20:08 GMT Message-Id: <201207270920.q6R9K8N8016183@freefall.freebsd.org> To: freebsd-scsi@FreeBSD.org From: "Steven Hartland" Cc: Subject: Re: kern/169974: [cam] [patch] add Quirks for SSD that are 4k optimised X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Steven Hartland List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2012 09:20:08 -0000 The following reply was made to PR kern/169974; it has been noted by GNATS. From: "Steven Hartland" To: Cc: Subject: Re: kern/169974: [cam] [patch] add Quirks for SSD that are 4k optimised Date: Fri, 27 Jul 2012 10:13:14 +0100 This is a multi-part message in MIME format. ------=_NextPart_000_12E9_01CD6BE0.6F334610 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original Content-Transfer-Encoding: 7bit Updated patch attached ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. ------=_NextPart_000_12E9_01CD6BE0.6F334610 Content-Type: text/plain; format=flowed; name="ssd_quirks.txt"; reply-type=original Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="ssd_quirks.txt" Adds 4K quirks for the following SSD's which all perform better when 4K = aligned=0A= and only except 4K deletes (TRIM):-=0A= * Corsair Force 2 & Force 3=0A= * OCZ Agility 3=0A= * OCZ Vertex 2 & Vertex 3=0A= * SuperTalent TeraDrive CT=0A= * Crucial RealSSD C300=0A= * XceedIOPS SATA=0A= * Intel 330 Series=0A= * OCZ Deneva R Series=0A= --- ./sys/cam/scsi/scsi_da.c.orig 2012-07-13 18:54:45.525693438 +0000=0A= +++ ./sys/cam/scsi/scsi_da.c 2012-07-13 18:55:06.959905372 +0000=0A= @@ -807,6 +807,86 @@=0A= { T_DIRECT, SIP_MEDIA_FIXED, "WDC WD??", "???PVT*", "*" },=0A= /*quirks*/DA_Q_4K=0A= },=0A= + {=0A= + /*=0A= + * Corsair Force 2 SSDs=0A= + * 4k optimised & trim only works in 4k requests + 4k aligned=0A= + */=0A= + { T_DIRECT, SIP_MEDIA_FIXED, "ATA", "Corsair CSSD-F*", "*" },=0A= + /*quirks*/DA_Q_4K=0A= + },=0A= + {=0A= + /*=0A= + * Corsair Force 3 SSDs=0A= + * 4k optimised & trim only works in 4k requests + 4k aligned=0A= + */=0A= + { T_DIRECT, SIP_MEDIA_FIXED, "ATA", "Corsair Force 3*", "*" },=0A= + /*quirks*/DA_Q_4K=0A= + },=0A= + {=0A= + /*=0A= + * OCZ Agility 3 SSDs=0A= + * 4k optimised & trim only works in 4k requests + 4k aligned=0A= + */=0A= + { T_DIRECT, SIP_MEDIA_FIXED, "ATA", "OCZ-AGILITY3*", "*" },=0A= + /*quirks*/DA_Q_4K=0A= + },=0A= + {=0A= + /*=0A= + * OCZ Vertex 2 SSDs (inc pro series)=0A= + * 4k optimised & trim only works in 4k requests + 4k aligned=0A= + */=0A= + { T_DIRECT, SIP_MEDIA_FIXED, "ATA", "OCZ?VERTEX2*", "*" },=0A= + /*quirks*/DA_Q_4K=0A= + },=0A= + {=0A= + /*=0A= + * OCZ Vertex 3 SSDs=0A= + * 4k optimised & trim only works in 4k requests + 4k aligned=0A= + */=0A= + { T_DIRECT, SIP_MEDIA_FIXED, "ATA", "OCZ-VERTEX3*", "*" },=0A= + /*quirks*/DA_Q_4K=0A= + },=0A= + {=0A= + /*=0A= + * SuperTalent TeraDrive CT SSDs=0A= + * 4k optimised & trim only works in 4k requests + 4k aligned=0A= + */=0A= + { T_DIRECT, SIP_MEDIA_FIXED, "ATA", "FTM??CT25H*", "*" },=0A= + /*quirks*/DA_Q_4K=0A= + },=0A= + {=0A= + /*=0A= + * Crucial RealSSD C300 SSDs=0A= + * 4k optimised=0A= + */=0A= + { T_DIRECT, SIP_MEDIA_FIXED, "ATA", "C300-CTFDDAC???MAG*",=0A= + "*" }, /*quirks*/DA_Q_4K=0A= + },=0A= + {=0A= + /*=0A= + * XceedIOPS SATA SSDs=0A= + * 4k optimised=0A= + */=0A= + { T_DIRECT, SIP_MEDIA_FIXED, "ATA", "SG9XCS2D*", "*" },=0A= + /*quirks*/DA_Q_4K=0A= + },=0A= + {=0A= + /*=0A= + * Intel 330 Series SSDs=0A= + * 4k optimised & trim only works in 4k requests + 4k aligned=0A= + */=0A= + { T_DIRECT, SIP_MEDIA_FIXED, "ATA", "INTEL SSDSC2ct*", "*" },=0A= + /*quirks*/DA_Q_4K=0A= + },=0A= + {=0A= + /*=0A= + * OCZ Deneva R Series SSDs=0A= + * 4k optimised & trim only works in 4k requests + 4k aligned=0A= + */=0A= + { T_DIRECT, SIP_MEDIA_FIXED, "ATA", "DENRSTE251M45*", "*" },=0A= + /*quirks*/DA_Q_4K=0A= + }=0A= };=0A= =0A= static disk_strategy_t dastrategy;=0A= --- sys/cam/ata/ata_da.c 2012-07-13 16:41:49.838471171 +0000=0A= +++ sys/cam/ata/ata_da.c 2012-07-18 12:14:49.189046166 +0000=0A= @@ -268,6 +268,86 @@=0A= /*quirks*/ADA_Q_4K=0A= },=0A= {=0A= + /*=0A= + * Corsair Force 2 SSDs=0A= + * 4k optimised & trim only works in 4k requests + 4k aligned=0A= + */=0A= + { T_DIRECT, SIP_MEDIA_FIXED, "*", "Corsair CSSD-F*", "*" },=0A= + /*quirks*/ADA_Q_4K=0A= + },=0A= + {=0A= + /*=0A= + * Corsair Force 3 SSDs=0A= + * 4k optimised & trim only works in 4k requests + 4k aligned=0A= + */=0A= + { T_DIRECT, SIP_MEDIA_FIXED, "*", "Corsair Force 3*", "*" },=0A= + /*quirks*/ADA_Q_4K=0A= + },=0A= + {=0A= + /*=0A= + * OCZ Agility 3 SSDs=0A= + * 4k optimised & trim only works in 4k requests + 4k aligned=0A= + */=0A= + { T_DIRECT, SIP_MEDIA_FIXED, "*", "OCZ-AGILITY3*", "*" },=0A= + /*quirks*/ADA_Q_4K=0A= + },=0A= + {=0A= + /*=0A= + * OCZ Vertex 2 SSDs (inc pro series)=0A= + * 4k optimised & trim only works in 4k requests + 4k aligned=0A= + */=0A= + { T_DIRECT, SIP_MEDIA_FIXED, "*", "OCZ?VERTEX2*", "*" },=0A= + /*quirks*/ADA_Q_4K=0A= + },=0A= + {=0A= + /*=0A= + * OCZ Vertex 3 SSDs=0A= + * 4k optimised & trim only works in 4k requests + 4k aligned=0A= + */=0A= + { T_DIRECT, SIP_MEDIA_FIXED, "ATA", "OCZ-VERTEX3*", "*" },=0A= + /*quirks*/ADA_Q_4K=0A= + },=0A= + {=0A= + /*=0A= + * SuperTalent TeraDrive CT SSDs=0A= + * 4k optimised & trim only works in 4k requests + 4k aligned=0A= + */=0A= + { T_DIRECT, SIP_MEDIA_FIXED, "*", "FTM??CT25H*", "*" },=0A= + /*quirks*/ADA_Q_4K=0A= + },=0A= + {=0A= + /*=0A= + * Crucial RealSSD C300 SSDs=0A= + * 4k optimised=0A= + */=0A= + { T_DIRECT, SIP_MEDIA_FIXED, "*", "C300-CTFDDAC???MAG*",=0A= + "*" }, /*quirks*/ADA_Q_4K=0A= + },=0A= + {=0A= + /*=0A= + * XceedIOPS SATA SSDs=0A= + * 4k optimised=0A= + */=0A= + { T_DIRECT, SIP_MEDIA_FIXED, "*", "SG9XCS2D*", "*" },=0A= + /*quirks*/ADA_Q_4K=0A= + },=0A= + {=0A= + /*=0A= + * Intel 330 Series SSDs=0A= + * 4k optimised & trim only works in 4k requests + 4k aligned=0A= + */=0A= + { T_DIRECT, SIP_MEDIA_FIXED, "*", "INTEL SSDSC2ct*", "*" },=0A= + /*quirks*/ADA_Q_4K=0A= + },=0A= + {=0A= + /*=0A= + * OCZ Deneva R Series SSDs=0A= + * 4k optimised & trim only works in 4k requests + 4k aligned=0A= + */=0A= + { T_DIRECT, SIP_MEDIA_FIXED, "*", "DENRSTE251M45*", "*" },=0A= + /*quirks*/ADA_Q_4K=0A= + },=0A= + {=0A= /* Default */=0A= {=0A= T_ANY, SIP_MEDIA_REMOVABLE|SIP_MEDIA_FIXED,=0A= ------=_NextPart_000_12E9_01CD6BE0.6F334610-- From owner-freebsd-scsi@FreeBSD.ORG Sat Jul 28 10:30:13 2012 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 42FBB106564A for ; Sat, 28 Jul 2012 10:30:13 +0000 (UTC) (envelope-from matyee.nmi@gmail.com) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id B65788FC0A for ; Sat, 28 Jul 2012 10:30:12 +0000 (UTC) Received: by laai10 with SMTP id i10so3169250laa.13 for ; Sat, 28 Jul 2012 03:30:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=eYizDXFKYyI+LwRfX1yT/FeBVyLe5dmJ+1T7vomDsuE=; b=M8cNQbHkTt93N0rRC/u2iTRaGcJOBdz7CUWnZFDqWOovyXAyQQ6pBgsoWuAL2apPyY CfLoyqzKnFYwmHD2/8ZdQSv7/0/sArEmgYjEhlbrPZeDQm/a/8r/z2SovlLHVeFHApp9 gD9wdy1fKknxbmByUVt/k9EzpgkzIWN3GBr+BkRzlovB+VtNTdvOfz5ay0obq79BSdDv Yu+hUlao99Han8HqUN972VldSP2NiiXPwSZbuZthw6my24QeVvTnGowohZCWjV8eGl8o lsgqj0K2Pq4sOrRIu7B6Uw3pFQf4TqZHD9G1gthAyzvLBH5sxBuOjaWTsDsYqvXwyPFk Q/IA== MIME-Version: 1.0 Received: by 10.152.144.234 with SMTP id sp10mr5416422lab.51.1343471406359; Sat, 28 Jul 2012 03:30:06 -0700 (PDT) Received: by 10.114.5.165 with HTTP; Sat, 28 Jul 2012 03:30:06 -0700 (PDT) Date: Sat, 28 Jul 2012 12:30:06 +0200 Message-ID: From: =?UTF-8?B?UMOpdGVyIFN6YWLDsw==?= To: freebsd-scsi@freebsd.org Content-Type: text/plain; charset=UTF-8 Subject: Multipath iSCSI X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jul 2012 10:30:13 -0000 Dear *, I have started to build a HA system. It runs a postgresql cluster with two nodes (master and hot stand-by, FreeBSD 9.0, postgresl 9.1). The storage for the database is provided by 2 separate systems (FreeBSD 9.0, iSCSI target, over ZFS). For the maximum redundancy I would like to use multipathing on the DB nodes. For me the best would be if the 2 DB nodes and the 2 storage nodes are all FreeBSD. Now I have 4 installed FreeBSD 9.0, iSCSI targets are in place, and the database nodes uses the exported targets as a storage. What is left is the multipath part. I have search a lot in this topic, but now I am really confused. I found some mails from this mailing list, the problem was the same, and there was no solution, but the mails are quite old (FreeBSD 7.3). I checked gmultipath, but it seems it is not the solution. Does FreeBSD support iSCSI multipath currently, or should I change the OS under the database nodes from FreeBSD to some linux distribution. I found a lot of working configuration for linux and iSCSI multipathing. Cheers, Matyee From owner-freebsd-scsi@FreeBSD.ORG Sat Jul 28 11:24:15 2012 Return-Path: Delivered-To: freebsd-scsi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C69951065670; Sat, 28 Jul 2012 11:24:15 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 994818FC17; Sat, 28 Jul 2012 11:24:14 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id OAA23542; Sat, 28 Jul 2012 14:24:06 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Sv57u-000LSo-AQ; Sat, 28 Jul 2012 14:24:06 +0300 Message-ID: <5013CBD2.60709@FreeBSD.org> Date: Sat, 28 Jul 2012 14:24:02 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120620 Thunderbird/13.0.1 MIME-Version: 1.0 To: Alexander Motin References: <500D54B9.1010800@FreeBSD.org> In-Reply-To: <500D54B9.1010800@FreeBSD.org> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: freebsd-scsi@FreeBSD.org, freebsd-geom@FreeBSD.org Subject: Re: [RFC] CAM/GEOM media change notification X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jul 2012 11:24:15 -0000 on 23/07/2012 16:42 Alexander Motin said the following: > Patch can be found here: > http://people.freebsd.org/~mav/mediachange8.patch Could you please rebase the patch for the latest head? Thank you. -- Andriy Gapon From owner-freebsd-scsi@FreeBSD.ORG Sat Jul 28 12:03:05 2012 Return-Path: Delivered-To: freebsd-scsi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5DC51106567B; Sat, 28 Jul 2012 12:03:05 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 361868FC2D; Sat, 28 Jul 2012 12:03:04 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id PAA23721; Sat, 28 Jul 2012 15:03:03 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Sv5ja-000LVF-Hr; Sat, 28 Jul 2012 15:03:02 +0300 Message-ID: <5013D4F5.7070401@FreeBSD.org> Date: Sat, 28 Jul 2012 15:03:01 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120620 Thunderbird/13.0.1 MIME-Version: 1.0 To: Alexander Motin References: <500D54B9.1010800@FreeBSD.org> <5013CBD2.60709@FreeBSD.org> In-Reply-To: <5013CBD2.60709@FreeBSD.org> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: freebsd-scsi@FreeBSD.org, freebsd-geom@FreeBSD.org Subject: Re: [RFC] CAM/GEOM media change notification X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jul 2012 12:03:05 -0000 on 28/07/2012 14:24 Andriy Gapon said the following: > on 23/07/2012 16:42 Alexander Motin said the following: >> Patch can be found here: >> http://people.freebsd.org/~mav/mediachange8.patch > > Could you please rebase the patch for the latest head? > Thank you. > Oops, sorry - my tree was out of sync with head. -- Andriy Gapon