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:
signature.asc
Description: This is a digitally signed message part.
