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=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 8FAF1C76195 for ; Mon, 22 Jul 2019 00:13:27 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 6F6232147A for ; Mon, 22 Jul 2019 00:13:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726444AbfGVAN0 (ORCPT ); Sun, 21 Jul 2019 20:13:26 -0400 Received: from mail104.syd.optusnet.com.au ([211.29.132.246]:57411 "EHLO mail104.syd.optusnet.com.au" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725904AbfGVAN0 (ORCPT ); Sun, 21 Jul 2019 20:13:26 -0400 Received: from dread.disaster.area (pa49-195-139-63.pa.nsw.optusnet.com.au [49.195.139.63]) by mail104.syd.optusnet.com.au (Postfix) with ESMTPS id 719A643C293; Mon, 22 Jul 2019 10:13:23 +1000 (AEST) Received: from dave by dread.disaster.area with local (Exim 4.92) (envelope-from ) id 1hpLvs-0000la-Jz; Mon, 22 Jul 2019 10:12:00 +1000 Date: Mon, 22 Jul 2019 10:12:00 +1000 From: Dave Chinner To: Damien Le Moal Cc: Jeff Moyer , "linux-fsdevel@vger.kernel.org" , "linux-xfs@vger.kernel.org" , Christoph Hellwig , Johannes Thumshirn , Hannes Reinecke , Ting Yao Subject: Re: [PATCH RFC] fs: New zonefs file system Message-ID: <20190722001200.GQ7689@dread.disaster.area> References: <20190712030017.14321-1-damien.lemoal@wdc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.2 cv=FNpr/6gs c=1 sm=1 tr=0 cx=a_idp_d a=fNT+DnnR6FjB+3sUuX8HHA==:117 a=fNT+DnnR6FjB+3sUuX8HHA==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=kj9zAlcOel0A:10 a=0o9FgrsRnhwA:10 a=7-415B0cAAAA:8 a=b07j5cj7HEDGNWPDeo4A:9 a=CjuIK1q_8ugA:10 a=biEYGPWJfzWAr4FL6Ov7:22 Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Sat, Jul 20, 2019 at 01:07:25AM +0000, Damien Le Moal wrote: > On 2019/07/19 23:25, Jeff Moyer wrote: > > I'll throw out another suggestion that may or may not work (I haven't > > given it much thought). Would it be possible to create a device mapper > > target that would export each zone as a separate block device? I > > understand that wouldn't help with the write pointer management, but it > > would allow you to create a single "file" for each zone. > > Well, I do not think you need a new device mapper for this. dm-linear supports > zoned block devices and will happily allow mapping a single zone and expose a > block device file for it. My problem with this approach is that SMR drives are > huge, and getting bigger. A 15 TB drive has 55380 zones of 256 MB. Upcoming 20 > TB drives have more than 75000 zones. Using dm-linear or any per-zone device > mapper target would create a huge resources pressure as the amount of memory > alone that would be used per zone would be much higher than with a file system > and the setup would also take far longer to complete compared to zonefs mount. Right, it's kinda insane to expect userspace to manage tens of thousands of "block devices" like this. You go run blkid on one of these devices, and what happens? Then there's stuff like udev overhead, grub os-probing that walks all block devices it can find, etc. Then consider putting hundreds of SMR drives into a machine that has multiple paths to each drive.... As such, I just don't think this block device approach is feasible, especially as Managing tens of thousands of individual small data regions in a storage device is exactly what filesystems are for. Cheers, Dave. -- Dave Chinner david@fromorbit.com