I don't think it's really possible to retrieve the list of "extents" sorted by device order, at
least not with the current on-disk format and not if you care about performance in any way.
Currently, to achieve that you'd need to do a global sort of all the DVAs/block pointers in the
entire file, which for large files could require a huge amount of I/O, memory resources and/or
time.
There is still a problem, though: we're only thinking about the top-level vdevs.
If you have a RAID-Z vdev with 10 disks, then a single block can be split across the 10 disks.
So the way we're thinking, for each block you'll only get 1 extent, where the offset is the
"logical" offset of the RAID-Z vdev. But in this way you won't get the actual per-disk offsets.
In theory you could return N FIEMAP extents per DMU block (where N is the number of disks you have
in the RAID-Z vdev), but this won't be as simple as looking at the DVAs (you'd need to do some
calculations), and I'd suspect the output would get a bit too verbose...
So maybe for now I'd suggest to only return 1 extent per block, with the logical offset, because if
the logical offsets are contiguous, then the per-disk offsets will also be contiguous.
Another question is - does filefrag understand that an allocated extent size may not correspond to
a logical extent size?
Because I was thinking that we need to return the actual "allocated" on-disk size, not the logical
block size, otherwise we won't know whether the blocks are actually allocated contiguously or if
they have holes between them (e.g. a RAID-Zed 128K block actually has an allocated size of
128K+parity, so it would seem that there are holes between RAID-Z blocks).
Another problem is that if we'd report the logical block size instead of the allocated size, it'd
get confusing if you have compression (it would look like some extents would be overlapping...).
But even then, I'm not sure if we can only get a per-block allocated size or if it's possible to
get a per-DVA allocated size...