From: Tvrtko Ursulin <tvrtko.ursulin@sophos.com>
To: Alexey Zaytsev <alexey.zaytsev@gmail.com>
Cc: Eric Paris <eparis@redhat.com>, Scott Hassan <hassan@dotfunk.com>,
Jan Kara <jack@suse.cz>, "agruen@linbit.com" <agruen@linbit.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"stefan@buettcher.org" <stefan@buettcher.org>,
Al Viro <viro@zeniv.linux.org.uk>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>
Subject: Re: [PATCH 4/4] fanotify: Expose the file changes to the user
Date: Fri, 26 Nov 2010 11:41:40 +0000 [thread overview]
Message-ID: <201011261141.40640.tvrtko.ursulin@sophos.com> (raw)
In-Reply-To: <AANLkTikRDyq4_rA5M7tiAuJJ7aa-pGfRj2YeqAmH5COA@mail.gmail.com>
On Friday 26 Nov 2010 11:21:18 Alexey Zaytsev wrote:
> On Fri, Nov 26, 2010 at 13:11, Tvrtko Ursulin <tvrtko.ursulin@sophos.com>
wrote:
> > On Monday 22 Nov 2010 00:37:21 Alexey Zaytsev wrote:
> >> +struct fanotify_opt_hdr {
> >> + __u8 type;
> >> + __u8 reserved;
> >> + __u16 len;
> >> + /* Payload goes here. */
> >> +};
> >> +
> >> +#define FANOTIFY_METADATA_VERSION 3
> >>
> >> struct fanotify_event_metadata {
> >> - __u16 event_len;
> >> + __u16 event_len; /* Including the options */
> >> __u8 vers;
> >> - __u8 reserved;
> >> + __u8 options_offset; /* Aka header length */
> >> __s32 fd;
> >> __aligned_u64 mask;
> >> __s32 pid;
> >> + /* Options go here. */
> >> };
> >
> > I am not 100% comfortable with having 16 bits length fields because I am
> > just not sure there is a measurable performance difference versus just
> > going with 32 bits.
>
> I'm not concerned so much with the performance, as with the storage.
> If we are generating events for every access on a mount point, some
> consumers might build a considerable backlog over a period of high
> activity. Would be good if we could cut the event size by 1/3 for
> free. And I don't see an event growing 64k even with the options. Do
> you?
I don't but maybe it is just lack of imagination.
My bias is that I am mostly thinking about synchronous events where large
backlog is not a realistic scenario. How realistic you think is this with
async events?
> > Also, options_offset is, if I understood it correctly, basically the
> > lenght of fanotify_event_metadata. As such, isn't that field redundant
> > since the lenght is implied from the protocol version?
>
> There are two problems there.
>
> 1) You lose backwards-compatibility. It's still an ABI breakage, even
> if you tell the users about it.
Assuming 2.6.37 release as starting point for ABI considerations?
> 2) You can't build a program to account for different fanotify versions:
> if (vers >= N) { use the cool stuff } else if {vers >= N-1} {
> still good }
I don't get why not, but maybe I am just slow today. There will always be 1:1
mapping from version to your options_offset field, no? How does then removing
options_offset change anything?
Tvrtko
Sophos Limited, The Pentagon, Abingdon Science Park, Abingdon, OX14 3YP, United Kingdom.
Company Reg No 2096520. VAT Reg No GB 991 2418 08.
next prev parent reply other threads:[~2010-11-26 11:41 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-22 0:31 [PATCH 0/4] Series short description Alexey Zaytsev
2010-11-22 0:33 ` [PATCH 1/4] fanotify: Shrink struct fanotify_event_metadata by 32 bits Alexey Zaytsev
2010-11-26 7:01 ` Alexey Zaytsev
2010-11-22 0:33 ` [PATCH 2/4] VFS: Tell fsnotify what part of the file might have changed Alexey Zaytsev
2010-11-22 0:33 ` [PATCH 3/4] fsnotify: Handle the file change ranges Alexey Zaytsev
2010-11-22 0:37 ` [PATCH 4/4] fanotify: Expose the file changes to the user Alexey Zaytsev
2010-11-26 10:11 ` Tvrtko Ursulin
2010-11-26 11:21 ` Alexey Zaytsev
2010-11-26 11:41 ` Tvrtko Ursulin [this message]
2010-11-26 12:11 ` Alexey Zaytsev
2010-11-29 16:14 ` Eric Paris
2010-11-29 16:51 ` Alexey Zaytsev
2010-11-29 18:14 ` Eric Paris
2010-11-29 17:11 ` Tvrtko Ursulin
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=201011261141.40640.tvrtko.ursulin@sophos.com \
--to=tvrtko.ursulin@sophos.com \
--cc=agruen@linbit.com \
--cc=alexey.zaytsev@gmail.com \
--cc=eparis@redhat.com \
--cc=hassan@dotfunk.com \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=stefan@buettcher.org \
--cc=viro@zeniv.linux.org.uk \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox