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=MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no 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 8BCB1C54FD0 for ; Tue, 21 Apr 2020 16:29:15 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 6946A206D5 for ; Tue, 21 Apr 2020 16:29:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728371AbgDUQ3P convert rfc822-to-8bit (ORCPT ); Tue, 21 Apr 2020 12:29:15 -0400 Received: from mail.kernel.org ([198.145.29.99]:48718 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726303AbgDUQ3P (ORCPT ); Tue, 21 Apr 2020 12:29:15 -0400 From: bugzilla-daemon@bugzilla.kernel.org To: linux-ext4@vger.kernel.org Subject: [Bug 207367] Accraid / aptec / Microsemi / ext4 / larger then 16TB Date: Tue, 21 Apr 2020 16:29:14 +0000 X-Bugzilla-Reason: None X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: AssignedTo fs_ext4@kernel-bugs.osdl.org X-Bugzilla-Product: File System X-Bugzilla-Component: ext4 X-Bugzilla-Version: 2.5 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: jack@suse.cz X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P1 X-Bugzilla-Assigned-To: fs_ext4@kernel-bugs.osdl.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT X-Bugzilla-URL: https://bugzilla.kernel.org/ Auto-Submitted: auto-generated MIME-Version: 1.0 Sender: linux-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org https://bugzilla.kernel.org/show_bug.cgi?id=207367 --- Comment #10 from Jan Kara (jack@suse.cz) --- On Tue 21-04-20 01:04:05, Christoph Hellwig wrote: > On Tue, Apr 21, 2020 at 03:08:50PM +1000, Dave Chinner wrote: > > > 4. fs/jbd2/journal.c > > > > Broken on filesystems where the journal file might be placed beyond > > a 32 bit block number, iomap_bmap() just makes that obvious. Needs > > fixing. > > I think this wants to use iomap, as that would solve all the problems. Well, there are two problems with this - firstly, ocfs2 is also using jbd2 and it knows nothing about iomap. So that would have to be implemented. Secondly, you have to somehow pass iomap ops to jbd2 so it all boils down to passing some callback to jbd2 during journal init to map blocks anyway as Dave said. And then it is upto filesystem to do the mapping - usually directly using its internal block mapping function - so no need for iomap AFAICT. Honza -- You are receiving this mail because: You are watching the assignee of the bug.