From owner-svn-src-all@freebsd.org Sun Dec 10 02:24:05 2017 Return-Path: Delivered-To: svn-src-all@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 5DD7FEA1151 for ; Sun, 10 Dec 2017 02:24:05 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (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 1E0097F57A for ; Sun, 10 Dec 2017 02:24:05 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x22d.google.com with SMTP id w127so6191310iow.11 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=WggoUJ7fD5bCTw9kZ4nB7dgToBZVj+zAjaNJMen0zN86+HtaDvuNwk4/dVEjLbMVc7 C3QNw6JJtwuUzXX0XcyOW7I6hkua7Ld+H9rQ4LImy6pg6dJfQLOPQbea9FJa8ECEwcdq H2vHmec/kQN7BWQYT5tI/oTbwZqv2axiRYIMOuXT+GwKvi42leKBefX5wn3DzrHhZAcE Ky04Vl0bUi1RjOuYutBLyajEYHtsJWmMM4lDGSyhyXUm14BoMvKhs33l4pdwxh536Jjh S+Cv0J6jGXvL26eZqdl9jIOSWQOX13qF3tNSDgUfGtYfHkGjqFDW/4mjMm9GlVApxOKu pAhQ== X-Gm-Message-State: AKGB3mKCybo1qrGpft4SqA6Stjz62CF3zaU23opL+Ftkpl/Cy1be7jSF +92ufpKaMySvc74Auwo1jf1AN7+IvfUkUdPCX9Wq0A== 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-all@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" 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