From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 50FF8C10F0E for ; Tue, 9 Apr 2019 12:27:38 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 295302084F for ; Tue, 9 Apr 2019 12:27:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726772AbfDIM1h (ORCPT ); Tue, 9 Apr 2019 08:27:37 -0400 Received: from mail-ot1-f41.google.com ([209.85.210.41]:45509 "EHLO mail-ot1-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726001AbfDIM1h (ORCPT ); Tue, 9 Apr 2019 08:27:37 -0400 Received: by mail-ot1-f41.google.com with SMTP id e5so15313638otk.12 for ; Tue, 09 Apr 2019 05:27:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=z/trgQiJ5D0wolVVcdbJRsKAhdLxgTEUNygK62iDo80=; b=GI0l3UUl1nJnRTvDQCHbTVEy/6qQlNafzdrnaTbYZ4+I7CxGcf4PdmYMwQozTk1+Ks 2yW+OYU0CKYuk3H/2O5tjxYMF1rk/IMy3R6BQz2rriW97dVb85KLzijxs0kAXDBteQDG EtmnCvW6thFWuY6rbbysRYScS8FSJZkzT+kEL/D7Ss0VE3BlVKmTBsF6oxg4rjFIo+/V 57Mq5RrF65jBWGj40zvFNQ3tEx/u/ZJSMAwbXU+FeCTaE3Cxuu32Mhch23ieLzM70Kox 4NnYi/QR7GFuGv/eGhmRUI1sT9JvCBngSuFiN3y+xlJfJ9RwllyVn+KdMUsn5ErVu782 KVCQ== X-Gm-Message-State: APjAAAVEsx7DQDzqhQx4kPDBjoXNdiT2wxMFKHzMKXghOKv3rZe2swE8 nD85Fv4idnbqiomGWiaFlQyhP+fQ+GbLfI5LB6cWAw== X-Google-Smtp-Source: APXvYqxRkNBis9kJov7vODTzte23h9mG5xtLuhpJGipOgzqSo/aswf6p88ymfgByWoZzTo2EibkGP01+RTjwIlBzdfQ= X-Received: by 2002:a05:6830:128c:: with SMTP id z12mr24617786otp.101.1554812856369; Tue, 09 Apr 2019 05:27:36 -0700 (PDT) MIME-Version: 1.0 References: <20190321131304.21618-1-agruenba@redhat.com> <20190328165104.GA21552@lst.de> <20190407073213.GA9509@lst.de> <20190408134405.GA15023@quack2.suse.cz> <20190409121508.GA9532@lst.de> In-Reply-To: <20190409121508.GA9532@lst.de> From: Andreas Gruenbacher Date: Tue, 9 Apr 2019 14:27:25 +0200 Message-ID: Subject: Re: gfs2 iomap dealock, IOMAP_F_UNBALANCED To: Christoph Hellwig Cc: Jan Kara , cluster-devel , Dave Chinner , Ross Lagerwall , Mark Syms , =?UTF-8?B?RWR3aW4gVMO2csO2aw==?= , linux-fsdevel , linux-mm@kvack.org Content-Type: text/plain; charset="UTF-8" Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Tue, 9 Apr 2019 at 14:15, Christoph Hellwig wrote: > On Mon, Apr 08, 2019 at 03:44:05PM +0200, Jan Kara wrote: > > > We won't be able to do a log flush while another transaction is > > > active, but that's what's needed to clean dirty pages. iomap doesn't > > > allow us to put the block allocation into a separate transaction from > > > the page writes; for that, the opposite to the page_done hook would > > > probably be needed. > > > > I agree that a ->page_prepare() hook would be probably the cleanest > > solution for this. > > That doesn't sound too bad to me. Okay, I'll see how the code for that will turn out. Thanks, Andreas From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andreas Gruenbacher Date: Tue, 9 Apr 2019 14:27:25 +0200 Subject: [Cluster-devel] gfs2 iomap dealock, IOMAP_F_UNBALANCED In-Reply-To: <20190409121508.GA9532@lst.de> References: <20190321131304.21618-1-agruenba@redhat.com> <20190328165104.GA21552@lst.de> <20190407073213.GA9509@lst.de> <20190408134405.GA15023@quack2.suse.cz> <20190409121508.GA9532@lst.de> Message-ID: List-Id: To: cluster-devel.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Tue, 9 Apr 2019 at 14:15, Christoph Hellwig wrote: > On Mon, Apr 08, 2019 at 03:44:05PM +0200, Jan Kara wrote: > > > We won't be able to do a log flush while another transaction is > > > active, but that's what's needed to clean dirty pages. iomap doesn't > > > allow us to put the block allocation into a separate transaction from > > > the page writes; for that, the opposite to the page_done hook would > > > probably be needed. > > > > I agree that a ->page_prepare() hook would be probably the cleanest > > solution for this. > > That doesn't sound too bad to me. Okay, I'll see how the code for that will turn out. Thanks, Andreas