From owner-svn-src-head@freebsd.org Sun Dec 10 02:24:05 2017 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 53C4BEA1150 for ; Sun, 10 Dec 2017 02:24:05 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 139E77F579 for ; Sun, 10 Dec 2017 02:24:05 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x232.google.com with SMTP id h12so6211700iof.6 for ; Sat, 09 Dec 2017 18:24:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=zrcUHiRcARmFrsYgJBLtVygOSPSsKkDW/iiMClE4Eno=; b=1hbscbL+KTSsxTwet2BrMltM3JaogACjbxHMZ+6kzTjNsB1rEE3tUeQkMNGE9NS8Zb kibwzRy2G/6Zft3ccrZL0P3NmjtHk23aaj9pPzZD38oM7LFlk+3LscVdQxfOB1YjMNgz fDOW1oEWM0GolinhDIncoW7ZMEyVqXrkUBki32uikzjTUbbqnW8XQXhvQH3YsOnMsdn3 5BlP8w6+fo/HN7XmJpQwuDJQ/OBCd6AXr96Ajnjpvgit61zcyfEqHc9kG/gsq/gUIJ7r beYykYlZySrSRywduGktHEgk7B3fcb9zvZpFsXQjz4WuTU3DtfP/SJb1rtv5QTG1AAm8 tW8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=zrcUHiRcARmFrsYgJBLtVygOSPSsKkDW/iiMClE4Eno=; b=qVqysPTF5UpaRL6rf6HWfaMrapDEeKXm3gPeXzsm50rmvYMJsOqmZ5PpXlkjnb4uOP 0kE5KYbm4jB/0IBauwBnqQbJuXRmqCDfGJhMjponhsr9sJ89fGRod5sQ/fAclBVnwymf R7UdAKdRqcQzos2jzHesmcM0F9napt/dJq54RsHdb6ao5/cq3BCQuj87KsfWwwozbMi2 52KpLNbXY/Bl909/fJj04A3IELA0keih2Ll8b70d7Ty0RQob2H1hNuY3UsgeHxHHHO7O GwUEYDTTLO1/feeAxMQDMksp+CxIHo/0T4cl/nqVcAFNqmRf6EHHrdDexeiRFhru3vrl JzBA== X-Gm-Message-State: AKGB3mLkI1HgEVMxU/E4OVGa3X08BtQx9C8Mz8VguabBU//tCA3+50OM JfDrDJ8ewer7sS7tOaRA//TqTRbZ76PmKMJA8P+NwQ== X-Google-Smtp-Source: AGs4zMbH9F/uBdNTR0zyhCuSZTWTzvVzkf9Ps5istsPgTfpE9rNZiI9MbwJ7LzPFDLRt2o4Om3GZ3bE+3Z3As9WhFIs= X-Received: by 10.107.52.140 with SMTP id b134mr22095560ioa.291.1512872644353; Sat, 09 Dec 2017 18:24:04 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.108.204 with HTTP; Sat, 9 Dec 2017 18:24:03 -0800 (PST) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: <73337.1512865023@critter.freebsd.dk> References: <201712091544.vB9FiVUI096790@repo.freebsd.org> <20171209223713.GA15275@raichu> <73189.1512862030@critter.freebsd.dk> <73337.1512865023@critter.freebsd.dk> From: Warner Losh Date: Sat, 9 Dec 2017 19:24:03 -0700 X-Google-Sender-Auth: 73NDfp6b_zr-rySukRAgTvAtVN0 Message-ID: Subject: Re: svn commit: r326731 - head/sys/ufs/ffs To: Poul-Henning Kamp Cc: Mark Johnston , Andriy Gapon , src-committers , "svn-src-all@freebsd.org" , "svn-src-head@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Dec 2017 02:24:05 -0000 On Sat, Dec 9, 2017 at 5:17 PM, Poul-Henning Kamp wrote: > -------- > In message Pg@mail.gmail.com>, Warner Losh writes: > > >That would be strange given that BIO_ORDERED is @gibbs baby ? > > > >Nah... I wrote the iosched code... and I find the concept somewhat flawed > >since it is at the disk level, not the partition level, so it winds up > >interfering with mixed traffic. And it really only makes sense for writes, > >but it affects reads. And it is a poor fit to Ata semantics, and not a lot > >better for scsi. And for nvme it creates a bottleneck in hardware > carefully > >designed to be free of bottlenecks... > > Don't take my comment as an endorsement of BIO_ORDERED... > > I think ordering is strictly a consumer responsibility for exactly > (and then some) of the reasons you mention. > > "End to end principle in systems design" and all that... Yes. I'd like to kill it completely... It's not needed and fosters the notion that there's more determinism in the ordering of events in the I/O stack than has existed since tagged queueing was a thing in the 90's. But there's no such thing as barriers in I/O devices today: that's handled in software by draining the queue, doing the one I/O, then starting the queue back up again.... So I'm with you that it's the client's job to wait for write X to complete before scheduling writes that depend on X to the I/O system. Warner