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.5 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,USER_AGENT_MUTT 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 ECD2EC169C4 for ; Mon, 11 Feb 2019 21:34:27 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id C375021773 for ; Mon, 11 Feb 2019 21:34:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727253AbfBKVe1 (ORCPT ); Mon, 11 Feb 2019 16:34:27 -0500 Received: from ipmail03.adl6.internode.on.net ([150.101.137.143]:32691 "EHLO ipmail03.adl6.internode.on.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727172AbfBKVe0 (ORCPT ); Mon, 11 Feb 2019 16:34:26 -0500 Received: from ppp59-167-129-252.static.internode.on.net (HELO dastard) ([59.167.129.252]) by ipmail03.adl6.internode.on.net with ESMTP; 12 Feb 2019 08:04:25 +1030 Received: from dave by dastard with local (Exim 4.80) (envelope-from ) id 1gtJDb-0002Ef-G1; Tue, 12 Feb 2019 08:34:23 +1100 Date: Tue, 12 Feb 2019 08:34:23 +1100 From: Dave Chinner To: Andreas Dilger Cc: Matthew Wilcox , Carlos Maiolino , linux-fsdevel , Christoph Hellwig , darrick.wong@oracle.com Subject: Re: Extending FIEMAP ioctl to report device id Message-ID: <20190211213423.GF20493@dastard> References: <20190211094306.fjr6gfehcstm7eqq@hades.usersys.redhat.com> <20190211152345.GC12668@bombadil.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Mon, Feb 11, 2019 at 01:52:25PM -0700, Andreas Dilger wrote: > On Feb 11, 2019, at 8:23 AM, Matthew Wilcox wrote: > > > > On Mon, Feb 11, 2019 at 10:43:06AM +0100, Carlos Maiolino wrote: > >> - The general idea, is to provide a way for FIEMAP ioctls to return the device > >> id where each extent is physically located. > > > > How does userspace get to use this information? If I call fiemap() and > > it tells me extent 1 is on device 0x12345678 and extent 2 is on device > > 0x34567812, what can I do with that information? > > For filesystems that may store a file on different devices, filefrag will > print out which device the file is located on, so that users can see where > the file is located. I suspect that even for XFS, we'd return a special cookie to say "On data device #X", "on real time device #Y" or "on subvolume #Z" rather than an actual block device. That will have a lot more meaning to the XFS filesystem utilities that might use this information than a raw block device (which may or may not exist!) because then they don't have to jump through hoops to convert it to something meaningful.... > > Darrick said it was useful for _inside_ the kernel. How is it useful > > for outside the kernel? > > In my experience, this can be very useful for users to understand how their > file is allocated if there are performance or other issues with a particular > device. *nod* And when you have allocation policies that select different devices for different files it makes it possible to easily verify the policy is working correctly. https://patchwork.kernel.org/patch/10081163/ > Also, in some respects, it is _required_ for multi-device filesystems, > since it makes it clear that block 123 on one device is not related to the same > block number on a different device. *nod* On xfs, we have to do 'xfs_io -c stat -c "fiemap -v" ' to get the RT dev attribute in addition to the extent list right now. It would be good to get them in just the fiemap call. Cheers, Dave. -- Dave Chinner david@fromorbit.com