On Mon, Feb 11, 2019 at 01:52:25PM -0700, Andreas Dilger wrote: > On Feb 11, 2019, at 8:23 AM, Matthew Wilcox <willy@xxxxxxxxxxxxx> 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" <file>' 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@xxxxxxxxxxxxx