inotify like service for an entire mount point?

inotify like service for an entire mount point?

[Greg Freemyer]

John, Robert, others,

I'm working with the ohsm team on a new kernel module and we need a
way as an example to be notified of every file creation event on a
filesystem so we can determine which storage tier a new file should be
allocating data blocks from.

I believe inotify needs a watch item for every directory it is
watching, so in theory we could walk the directory structure somehow
and register every directory with inotify.  That seems like an
excessive amount of overhead for what seems like a simple to implement
need.

So a couple questions:

Can inotify currently be told to monitor an entire mount point?

Would a patch to enable inotify to do so be entertained?  If so, what
about one that added the ability to just the kernel API.  (We have no
need of it in userspace at present.)

Is there an alternate pre-existing linux kernel solution?

Thanks
Greg
-- 
Greg Freemyer
Head of EDD Tape Extraction and Processing team
Litigation Triage Solutions Specialist
http://www.linkedin.com/in/gregfreemyer
Preservation and Forensic processing of Exchange Repositories White Paper -
<http://www.norcrossgroup.com/forms/whitepapers/tng_whitepaper_fpe.html>

The Norcross Group
The Intersection of Evidence & Technology
http://www.norcrossgroup.com

Re: inotify like service for an entire mount point?

[SandeepKsinha]

Hi Greg,

On Mon, Aug 3, 2009 at 8:45 PM, Greg Freemyer<greg.freemyer@gmail.com> wrote:
>
> John, Robert, others,
>
> I'm working with the ohsm team on a new kernel module and we need a
> way as an example to be notified of every file creation event on a
> filesystem so we can determine which storage tier a new file should be
> allocating data blocks from.
>
> I believe inotify needs a watch item for every directory it is
> watching, so in theory we could walk the directory structure somehow
> and register every directory with inotify.  That seems like an
> excessive amount of overhead for what seems like a simple to implement
> need.
Look for:

int inotifytools_watch_recursively (char const *path, int events) on
http://inotify-tools.sourceforge.net/api/inotifytools_8h.html


>
> So a couple questions:
>
> Can inotify currently be told to monitor an entire mount point?
>

May be the above could help.

> Would a patch to enable inotify to do so be entertained?  If so, what
> about one that added the ability to just the kernel API.  (We have no
> need of it in userspace at present.)
>
> Is there an alternate pre-existing linux kernel solution?
>

Is the mapping functionality for (inotifytools_watch_recursively)
exported in the kernel.

It would really be great if we hear from the experts.
Kindly suggest. And correct me If I am gone wrong somewhere.


> Thanks
> Greg
> --
> Greg Freemyer
> Head of EDD Tape Extraction and Processing team
> Litigation Triage Solutions Specialist
> http://www.linkedin.com/in/gregfreemyer
> Preservation and Forensic processing of Exchange Repositories White Paper -
> <http://www.norcrossgroup.com/forms/whitepapers/tng_whitepaper_fpe.html>
>
> The Norcross Group
> The Intersection of Evidence & Technology
> http://www.norcrossgroup.com
>


we can specify the mount point

i suppose to watch
11:29 PM
this was the last release

1 January 2008: inotify-tools 3.13 released. Changes:

Fix: `--timefmt' option to inotifywait doesn't work (broken in 3.12)

http://inotify-tools.sourceforge.net/

will it support the new kernel

Regards,
Sandeep.

> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the Google Groups "fscops" group.
> To post to this group, send email to fscops@googlegroups.com
> To unsubscribe from this group, send email to fscops+unsubscribe@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/fscops?hl=en
> -~----------~----~----~----~------~----~------~--~---
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html