All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dmitry Monakhov <dmonakhov@openvz.org>
To: Dave Chinner <david@fromorbit.com>,
	Christoph Hellwig <hch@infradead.org>
Cc: linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH] ext4: add generic uevent infrastructure
Date: Tue, 19 Nov 2013 13:35:36 +0400	[thread overview]
Message-ID: <87ob5gohsn.fsf@openvz.org> (raw)
In-Reply-To: <20131119013621.GH11434@dastard>

On Tue, 19 Nov 2013 12:36:21 +1100, Dave Chinner <david@fromorbit.com> wrote:
> On Mon, Nov 18, 2013 at 08:20:45AM -0800, Christoph Hellwig wrote:
> > On Mon, Nov 18, 2013 at 06:38:40PM +0400, Dmitry Monakhov wrote:
> > > *Purpose:
> > > It is reasonable to annaunce fs related events via uevent infrastructure.
> > > This patch implement only ext4'th part, but IMHO this should be usefull for
> > > any generic filesystem.
> > 
> > It does indeed look very generic.  How about you try to redo it to sit
> > at the VFS level?
> 
> I certain agree with that. I'd also like to see ENOSPC notifications
> as that would obliviate the need for distros like RHEL to ship
> systemtap scripts to generate such notifications for admins....
Good point. This may be classified as NON_FATAL_ERROR. Will add this to
next version. But this event type may require some-sort of rate limiting.
> 
> > Also Jan Kara has done quota netlink notifications a while ago, which
> > fit into the same sort of niche.
> 
> The question I'm asking is whether we really want a new interface
> for these events? Shouldn't we really try to use an existing
> filesystem event interface for generating these events (e.g.
> fanotify) rather than adding yet another disjoint filesystem event
> interface to the kernel?
ASAIU fanotify is file-oriented event interface API aimed for antivirus
and index applications. fanotify_event_set = {ACCESS_XXX,OPEN,MODIFY, CLOSE_XXX}
But I want to emmit fs-oriented events (where SB is the object)
fs_event_set = {MOUNT,UMOUNT,FREEZE,UNFREEZE,ERROR,ENOSPC}.
IMHO fs_event_set is closer to {dm,device}_events_set than
fanotify_event_set, that is why I use idea of uevent for devices.
And new fs-events look as intuitive extension of existing dev-event API.
Are you agree?
> 
> Cheers,
> 
> Dave.
> -- 
> Dave Chinner
> david@fromorbit.com
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2013-11-19  9:35 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-18 14:38 [PATCH] ext4: add generic uevent infrastructure Dmitry Monakhov
2013-11-18 16:20 ` Christoph Hellwig
2013-11-19  1:36   ` Dave Chinner
2013-11-19  9:35     ` Dmitry Monakhov [this message]
2013-11-19 10:25     ` Christoph Hellwig
2013-11-19 11:17       ` Jan Kara

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87ob5gohsn.fsf@openvz.org \
    --to=dmonakhov@openvz.org \
    --cc=david@fromorbit.com \
    --cc=hch@infradead.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.