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=-3.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED,USER_AGENT_NEOMUTT 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 0A42AC169C4 for ; Mon, 11 Feb 2019 09:43:13 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id D80CD20818 for ; Mon, 11 Feb 2019 09:43:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726041AbfBKJnM (ORCPT ); Mon, 11 Feb 2019 04:43:12 -0500 Received: from mail-wm1-f47.google.com ([209.85.128.47]:33640 "EHLO mail-wm1-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725996AbfBKJnM (ORCPT ); Mon, 11 Feb 2019 04:43:12 -0500 Received: by mail-wm1-f47.google.com with SMTP id h22so13986549wmb.0 for ; Mon, 11 Feb 2019 01:43:11 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:mime-version :content-disposition:user-agent; bh=jPRHChofLs3/tFyuZ24oFIa3w14W6TDOB3rWXVo46aU=; b=HQ/NguvAoPdiEGuXw4SInc9u/jvusdw7IYJl6pdu4aFplyIEmZLa4/Vt5Iip5xEzx1 lQiO5E80In4MOWHtVKVE4lsMpSimR3jYk9u4aEQR9gLQl6pvD8a3x4RO2PIobdsjK9n6 8+S4hTnLpNDkl5Hq7y8uRaO1nm8V8UOn6Csdo1ihpp2MH1hAzeNv5WywZZ/7hDpe4ubr bNO102OyBKeVPPSDbR1hv5E93AnXS1G1H+dNSDQNWI5RHok8OjGk4bNXygAIsxs0Z7cD CZXMxg7NCkDJs/wiZjsQCyonGlmX0BLVIP0XrmIFDj0TjsGOy6J0OM8rOHUfc0J86ydB jQiw== X-Gm-Message-State: AHQUAubd3ZtUEsFh8DhThhO4DGRTWnF6llXeD3Mkzfm3QxMQ49tRaOcv 03S3e2cYxw33gPSe5zgvOOeL57B+ZHY= X-Google-Smtp-Source: AHgI3IbBKXy/+WxT8p0jBTrReQisTwLrjLpD3tOrBNgul5eGunb9fYKjhFLNQmmPj52apdq2wooUHA== X-Received: by 2002:adf:a211:: with SMTP id p17mr26124501wra.179.1549878189919; Mon, 11 Feb 2019 01:43:09 -0800 (PST) Received: from hades.usersys.redhat.com (ip-89-103-126-188.net.upcbroadband.cz. [89.103.126.188]) by smtp.gmail.com with ESMTPSA id j3sm12541592wmb.39.2019.02.11.01.43.08 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 11 Feb 2019 01:43:09 -0800 (PST) Date: Mon, 11 Feb 2019 10:43:06 +0100 From: Carlos Maiolino To: linux-fsdevel@vger.kernel.org Cc: hch@lst.de, adilger@dilger.ca, darrick.wong@oracle.com Subject: Extending FIEMAP ioctl to report device id Message-ID: <20190211094306.fjr6gfehcstm7eqq@hades.usersys.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: NeoMutt/20180716 Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org Hi. A discussion has been started on another thread [1], with the idea of extending FIEMAP ioctl interface, to also report the device id where the extents being reported are physically located. I've started to work on the extension, but, before I spend time implementing it, I'd rather start a discussion to ensure it's really feasible or just a waste of time in pursuing it. The whole context, can be found in the thread [1], more specifically in the discussion started on patch 9, here [2]. About the proposal: - The general idea, is to provide a way for FIEMAP ioctls to return the device id where each extent is physically located. - This is particularly useful for those filesystems where the file extents are located on a different block device other than that associated with the superblock , for example, btrfs using multiple devices, and XFS when using a real-time device. Achieving this is relatively easy, using one of the __u32 fe_reserved fields in struct fiemap_extent, to create a new field (__u32 fe_device), which can be used for two purposes, based on two new FIEMAP_EXTENT_ flags : - FIEMAP_EXTENT_DEVICE: which will indicate the fiemap_extent.fe_device contains the major/minor numbers of the block device where the specific extent is located - FIEMAP_EXTENT_COOKIE (of _EXTENT_PRIVATE), which indicates the fiemap_extent.fe_device will contain a special meaning depending on the fs. Such flag sounded interesting for distributed filesystems, which could use this field for example, to specify each node of the cluster (or whatever other name is defined by the specific fs) that specific extent is located. As mentioned before, implementing it, looks not that difficult, considering such reserved fields are not to be touched by userspace, and using one of the new fields won't break any current userspace application which doesn't understand the new data. But still, things which are worth to discuss is if such information (the physical location of the extents) is something that should be exported to userspace or not. Any comments if this is something worth to implement or not, are welcome. Cheers [1] https://www.spinics.net/lists/linux-fsdevel/msg136559.html [2] https://www.spinics.net/lists/linux-fsdevel/msg136568.html -- Carlos