reiser4: FITRIM ioctl -- where to place the handler?

reiser4: FITRIM ioctl -- where to place the handler?

[Ivan Shapovalov]

[-- Attachment #1: Type: text/plain, Size: 724 bytes --]

Hi,

I've started to iterate on the batch mode discard implementation for reiser4,
and the first question is -- where to place the ioctl handler?

From what I've been able to understand, we need something like
reiser4_ioctl_dir_common() in plugin/file_ops.c, pointer to which should
become ->{unlocked,compat}_ioctl() of directory_f_ops in plugin/object.c.

However, in this case, what is DIRECTORY_FILE_PLUGIN_ID and corresponding
entry in file_plugins array in plugin/object.c? How is it related to
directories?

I see that its ->{inode,file,as}_ops are empty, so it probably does not
participate in dispatching ioctls, but I'd like to make sure this is the case.

Thanks,
-- 
Ivan Shapovalov / intelfx /

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 213 bytes --]

Re: reiser4: FITRIM ioctl -- where to place the handler?

[Edward Shishkin]

Do we really need this ioctl?
If we implement precise discard (with garbage collection),
then I don't see any applications for this ioctl..

Edward.


On 07/31/2014 04:23 PM, Ivan Shapovalov wrote:
> Hi,
>
> I've started to iterate on the batch mode discard implementation for reiser4,
> and the first question is -- where to place the ioctl handler?
>
>  From what I've been able to understand, we need something like
> reiser4_ioctl_dir_common() in plugin/file_ops.c, pointer to which should
> become ->{unlocked,compat}_ioctl() of directory_f_ops in plugin/object.c.
>
> However, in this case, what is DIRECTORY_FILE_PLUGIN_ID and corresponding
> entry in file_plugins array in plugin/object.c? How is it related to
> directories?
>
> I see that its ->{inode,file,as}_ops are empty, so it probably does not
> participate in dispatching ioctls, but I'd like to make sure this is the case.
>
> Thanks,

Re: reiser4: FITRIM ioctl -- where to place the handler?

[Ivan Shapovalov]

[-- Attachment #1: Type: text/plain, Size: 1409 bytes --]

On Thursday 31 July 2014 at 23:37:34, Edward Shishkin wrote:	
> Do we really need this ioctl?
> If we implement precise discard (with garbage collection),
> then I don't see any applications for this ioctl..
> 
> Edward.

I think that we need it: think of unclean unmounts, fs corruptions (fsck does
not discard new free space), forgotten 'discard' mount option, etc...

Having as much discarded space as possible is important not only for having
faster writes, but also for the background firmware-based wear leveling to
function efficiently.

-- 
Ivan Shapovalov / intelfx /
> 
> 
> On 07/31/2014 04:23 PM, Ivan Shapovalov wrote:
> > Hi,
> >
> > I've started to iterate on the batch mode discard implementation for reiser4,
> > and the first question is -- where to place the ioctl handler?
> >
> >  From what I've been able to understand, we need something like
> > reiser4_ioctl_dir_common() in plugin/file_ops.c, pointer to which should
> > become ->{unlocked,compat}_ioctl() of directory_f_ops in plugin/object.c.
> >
> > However, in this case, what is DIRECTORY_FILE_PLUGIN_ID and corresponding
> > entry in file_plugins array in plugin/object.c? How is it related to
> > directories?
> >
> > I see that its ->{inode,file,as}_ops are empty, so it probably does not
> > participate in dispatching ioctls, but I'd like to make sure this is the case.
> >
> > Thanks,
> 

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 213 bytes --]