Re: [PATCH 1/3] ext4: return the extent cache information via fiemap

Re: [PATCH 1/3] ext4: return the extent cache information via fiemap

[Christoph Hellwig]

On Fri, Aug 09, 2019 at 02:18:29PM -0400, Theodore Ts'o wrote:
> For debugging reasons, it's useful to know the contents of the extent
> cache.  Since the extent cache contains much of what is in the fiemap
> ioctl, extend the fiemap interface to return this information via some
> ext4-specific flags.

Nak.  No weird fs specific fiemap flags that aren't even in the uapi
header.  Please provide your own debug only interface.

Re: [PATCH 1/3] ext4: return the extent cache information via fiemap

[Theodore Y. Ts'o]

On Sat, Aug 10, 2019 at 12:33:43AM -0700, Christoph Hellwig wrote:
> 
> On Fri, Aug 09, 2019 at 02:18:29PM -0400, Theodore Ts'o wrote:
> > For debugging reasons, it's useful to know the contents of the extent
> > cache.  Since the extent cache contains much of what is in the fiemap
> > ioctl, extend the fiemap interface to return this information via some
> > ext4-specific flags.
> 
> Nak.  No weird fs specific fiemap flags that aren't even in the uapi
> header.  Please provide your own debug only interface.

I can understand why you don't like this from the principle of the
thing.

I'll create my own ioctl, and make a copy of ioctl_fiemap() into ext4
and modify it for my needs.  I was trying to avoid needing to do that,
since there is plenty of space in the fiemap flags to carve out space
for file-specific specific flags, and avoiding making extra copies of
code for the purposes of reuse weighed more heavily than "no
fs-specific fiemap flags".

						- Ted

Re: [PATCH 1/3] ext4: return the extent cache information via fiemap

[Christoph Hellwig]

On Sun, Aug 11, 2019 at 12:15:08PM -0400, Theodore Y. Ts'o wrote:
> > Nak.  No weird fs specific fiemap flags that aren't even in the uapi
> > header.  Please provide your own debug only interface.
> 
> I can understand why you don't like this from the principle of the
> thing.

I think mixing up in-kernel temporary state with the on-disk layout
is a bad idea, yes.  I think it is an even worse idea to try to sneak
it in without API review in an undocumented fashion.

> 
> I'll create my own ioctl, and make a copy of ioctl_fiemap() into ext4
> and modify it for my needs.  I was trying to avoid needing to do that,
> since there is plenty of space in the fiemap flags to carve out space
> for file-specific specific flags, and avoiding making extra copies of
> code for the purposes of reuse weighed more heavily than "no
> fs-specific fiemap flags".

I think dumping your internal state is a candidate for debugs, not
a copy of ioctl_fiemap.