All of lore.kernel.org
 help / color / mirror / Atom feed
From: Beata Michalska <b.michalska@samsung.com>
To: Hugh Dickins <hughd@google.com>
Cc: Eric Sandeen <sandeen@redhat.com>,
	Tim Chen <tim.c.chen@linux.intel.com>,
	linux-kernel@vger.kernel.org, tytso@mit.edu,
	adilger.kernel@dilger.ca, lczerner@redhat.com, hch@infradead.org,
	linux-ext4@vger.kernel.org, linux-mm@kvack.org,
	kyungmin.park@samsung.com, kmpark@infradead.org,
	Linux Filesystem Mailing List <linux-fsdevel@vger.kernel.org>,
	linux-api@vger.kernel.org
Subject: Re: [RFC 1/4] fs: Add generic file system event notifications
Date: Fri, 17 Apr 2015 11:10:58 +0200	[thread overview]
Message-ID: <5530CE22.8080903@samsung.com> (raw)
In-Reply-To: <alpine.LSU.2.11.1504161229450.17935@eggly.anvils>

Hi,

On 04/16/2015 10:10 PM, Hugh Dickins wrote:
> On Thu, 16 Apr 2015, Beata Michalska wrote:
>> On 04/16/2015 05:46 AM, Eric Sandeen wrote:
>>> On 4/15/15 2:15 AM, Beata Michalska wrote:
>>>> Introduce configurable generic interface for file
>>>> system-wide event notifications to provide file
>>>> systems with a common way of reporting any potential
>>>> issues as they emerge.
>>>>
>>>> The notifications are to be issued through generic
>>>> netlink interface, by a dedicated, for file system
>>>> events, multicast group. The file systems might as
>>>> well use this group to send their own custom messages.
>>>
>>> ...
>>>
>>>> + 4.3 Threshold notifications:
>>>> +
>>>> + #include <linux/fs_event.h>
>>>> + void fs_event_alloc_space(struct super_block *sb, u64 ncount);
>>>> + void fs_event_free_space(struct super_block *sb, u64 ncount);
>>>> +
>>>> + Each filesystme supporting the treshold notifiactions should call
>>>> + fs_event_alloc_space/fs_event_free_space repsectively whenever the
>>>> + ammount of availbale blocks changes.
>>>> + - sb:     the filesystem's super block
>>>> + - ncount: number of blocks being acquired/released
>>>
>>> so:
>>>
>>>> +void fs_event_alloc_space(struct super_block *sb, u64 ncount)
>>>> +{
>>>> +	struct fs_trace_entry *en;
>>>> +	s64 count;
>>>> +
>>>> +	spin_lock(&fs_trace_lock);
>>>
>>> Every allocation/free for every supported filesystem system-wide will be
>>> serialized on this global spinlock?  That sounds like a non-starter...
>>>
>>> -Eric
>>>
>> I guess there is a plenty room for improvements as this is an early version.
>> I do agree that this might be a performance bottleneck event though I've tried
>> to keep this to minimum - it's being taken only for hashtable look-up. But still...
>> I was considering placing the trace object within the super_block to skip
>> this look-up part but I'd like to gather more comments, especially on the concept
>> itself.
> 
> Sorry, I have no opinion on the netlink fs notifications concept
> itself, not my area of expertise at all.
> 
> No doubt you Cc'ed me for tmpfs: I am very glad you're now trying the
> generic filesystem route, and yes, I'd be happy to have the support
> in tmpfs, thank you - if it is generally agreed to be suitable for
> filesystems; but wouldn't want this as a special for tmpfs.
> 
> However, I must echo Eric's point: please take a look at 7e496299d4d2
> "tmpfs: make tmpfs scalable with percpu_counter for used blocks":
> Tim would be unhappy if you added overhead back into that path.
> 
> (And please Cc linux-fsdevel@vger.kernel.org next time you post these.)
> 
> Hugh
> 

Well, the concept of using netlink interface here is just a part of the overall
idea - so any comments are really welcomed here. The more of them the better solution
can be worked out, as I believe.

As for the possible overhead: this is the last thing I would want, so I'll
definitely do may best to not to introduce any. I will definitely rework this.

Thanks for Your comments,

BR
Beata



WARNING: multiple messages have this Message-ID (diff)
From: Beata Michalska <b.michalska@samsung.com>
To: Hugh Dickins <hughd@google.com>
Cc: Eric Sandeen <sandeen@redhat.com>,
	Tim Chen <tim.c.chen@linux.intel.com>,
	linux-kernel@vger.kernel.org, tytso@mit.edu,
	adilger.kernel@dilger.ca, lczerner@redhat.com, hch@infradead.org,
	linux-ext4@vger.kernel.org, linux-mm@kvack.org,
	kyungmin.park@samsung.com, kmpark@infradead.org,
	Linux Filesystem Mailing List <linux-fsdevel@vger.kernel.org>,
	linux-api@vger.kernel.org
Subject: Re: [RFC 1/4] fs: Add generic file system event notifications
Date: Fri, 17 Apr 2015 11:10:58 +0200	[thread overview]
Message-ID: <5530CE22.8080903@samsung.com> (raw)
In-Reply-To: <alpine.LSU.2.11.1504161229450.17935@eggly.anvils>

Hi,

On 04/16/2015 10:10 PM, Hugh Dickins wrote:
> On Thu, 16 Apr 2015, Beata Michalska wrote:
>> On 04/16/2015 05:46 AM, Eric Sandeen wrote:
>>> On 4/15/15 2:15 AM, Beata Michalska wrote:
>>>> Introduce configurable generic interface for file
>>>> system-wide event notifications to provide file
>>>> systems with a common way of reporting any potential
>>>> issues as they emerge.
>>>>
>>>> The notifications are to be issued through generic
>>>> netlink interface, by a dedicated, for file system
>>>> events, multicast group. The file systems might as
>>>> well use this group to send their own custom messages.
>>>
>>> ...
>>>
>>>> + 4.3 Threshold notifications:
>>>> +
>>>> + #include <linux/fs_event.h>
>>>> + void fs_event_alloc_space(struct super_block *sb, u64 ncount);
>>>> + void fs_event_free_space(struct super_block *sb, u64 ncount);
>>>> +
>>>> + Each filesystme supporting the treshold notifiactions should call
>>>> + fs_event_alloc_space/fs_event_free_space repsectively whenever the
>>>> + ammount of availbale blocks changes.
>>>> + - sb:     the filesystem's super block
>>>> + - ncount: number of blocks being acquired/released
>>>
>>> so:
>>>
>>>> +void fs_event_alloc_space(struct super_block *sb, u64 ncount)
>>>> +{
>>>> +	struct fs_trace_entry *en;
>>>> +	s64 count;
>>>> +
>>>> +	spin_lock(&fs_trace_lock);
>>>
>>> Every allocation/free for every supported filesystem system-wide will be
>>> serialized on this global spinlock?  That sounds like a non-starter...
>>>
>>> -Eric
>>>
>> I guess there is a plenty room for improvements as this is an early version.
>> I do agree that this might be a performance bottleneck event though I've tried
>> to keep this to minimum - it's being taken only for hashtable look-up. But still...
>> I was considering placing the trace object within the super_block to skip
>> this look-up part but I'd like to gather more comments, especially on the concept
>> itself.
> 
> Sorry, I have no opinion on the netlink fs notifications concept
> itself, not my area of expertise at all.
> 
> No doubt you Cc'ed me for tmpfs: I am very glad you're now trying the
> generic filesystem route, and yes, I'd be happy to have the support
> in tmpfs, thank you - if it is generally agreed to be suitable for
> filesystems; but wouldn't want this as a special for tmpfs.
> 
> However, I must echo Eric's point: please take a look at 7e496299d4d2
> "tmpfs: make tmpfs scalable with percpu_counter for used blocks":
> Tim would be unhappy if you added overhead back into that path.
> 
> (And please Cc linux-fsdevel@vger.kernel.org next time you post these.)
> 
> Hugh
> 

Well, the concept of using netlink interface here is just a part of the overall
idea - so any comments are really welcomed here. The more of them the better solution
can be worked out, as I believe.

As for the possible overhead: this is the last thing I would want, so I'll
definitely do may best to not to introduce any. I will definitely rework this.

Thanks for Your comments,

BR
Beata


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2015-04-17  9:11 UTC|newest]

Thread overview: 78+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-15  7:15 [RFC 0/4] Generic file system events interface Beata Michalska
2015-04-15  7:15 ` Beata Michalska
2015-04-15  7:15 ` [RFC 1/4] fs: Add generic file system event notifications Beata Michalska
2015-04-15  7:15   ` Beata Michalska
2015-04-15 19:25   ` Darrick J. Wong
2015-04-15 19:25     ` Darrick J. Wong
2015-04-16  8:22     ` Beata Michalska
2015-04-16  8:22       ` Beata Michalska
2015-04-17  8:48       ` Jan Kara
2015-04-17  8:48         ` Jan Kara
2015-04-16  3:46   ` Eric Sandeen
2015-04-16  3:46     ` Eric Sandeen
2015-04-16  8:41     ` Beata Michalska
2015-04-16  8:41       ` Beata Michalska
2015-04-16 20:10       ` Hugh Dickins
2015-04-16 20:10         ` Hugh Dickins
2015-04-17  9:10         ` Beata Michalska [this message]
2015-04-17  9:10           ` Beata Michalska
2015-04-16 21:56   ` Heinrich Schuchardt
2015-04-16 21:56     ` Heinrich Schuchardt
2015-04-17  9:46     ` Beata Michalska
2015-04-17  9:46       ` Beata Michalska
2015-04-17  9:46       ` Beata Michalska
2015-04-17 11:58     ` Jan Kara
2015-04-17 11:58       ` Jan Kara
2015-04-17 11:31   ` Jan Kara
2015-04-17 11:31     ` Jan Kara
2015-04-17 13:04     ` Beata Michalska
2015-04-17 13:04       ` Beata Michalska
2015-04-17 13:15       ` Beata Michalska
2015-04-17 13:15         ` Beata Michalska
2015-04-17 13:16       ` Jan Kara
2015-04-17 13:16         ` Jan Kara
2015-04-17 13:16         ` Jan Kara
2015-04-17 13:23       ` Austin S Hemmelgarn
2015-04-17 13:41         ` Jan Kara
2015-04-17 13:41           ` Jan Kara
2015-04-17 14:51         ` John Spray
2015-04-17 14:51           ` John Spray
2015-04-17 15:43           ` Jan Kara
2015-04-17 15:43             ` Jan Kara
2015-04-17 16:08             ` John Spray
2015-04-17 16:08               ` John Spray
2015-04-17 16:08               ` John Spray
2015-04-17 16:22               ` Jan Kara
2015-04-17 16:22                 ` Jan Kara
2015-04-17 16:22                 ` Jan Kara
2015-04-17 16:29                 ` Austin S Hemmelgarn
2015-04-17 16:39                   ` Jan Kara
2015-04-17 16:39                     ` Jan Kara
2015-04-17 16:39                     ` Jan Kara
2015-04-17 17:37                 ` John Spray
2015-04-17 17:37                   ` John Spray
2015-04-17 22:37                   ` Andreas Dilger
2015-04-17 22:37                     ` Andreas Dilger
2015-04-17 16:25               ` Beata Michalska
2015-04-17 16:25                 ` Beata Michalska
2015-04-17 16:25                 ` Beata Michalska
2015-04-17 22:44     ` Andreas Dilger
2015-04-17 22:44       ` Andreas Dilger
2015-04-20  8:56       ` Beata Michalska
2015-04-20  8:56         ` Beata Michalska
2015-04-20 10:32       ` Jan Kara
2015-04-20 10:32         ` Jan Kara
2015-04-15  7:15 ` [RFC 2/4] ext4: Add helper function to mark group as corrupted Beata Michalska
2015-04-15  7:15   ` Beata Michalska
2015-04-15  7:15 ` [RFC 3/4] ext4: Add support for generic FS events Beata Michalska
2015-04-15  7:15   ` Beata Michalska
2015-04-15 19:18   ` Darrick J. Wong
2015-04-15 19:18     ` Darrick J. Wong
2015-04-16  8:02     ` Beata Michalska
2015-04-16  8:02       ` Beata Michalska
2015-04-15  7:15 ` [RFC 4/4] shmem: " Beata Michalska
2015-04-15  7:15   ` Beata Michalska
2015-04-17  8:17 ` [RFC 0/4] Generic file system events interface Jan Kara
2015-04-17  8:17   ` Jan Kara
2015-04-17  9:10   ` Beata Michalska
2015-04-17  9:10     ` Beata Michalska

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=5530CE22.8080903@samsung.com \
    --to=b.michalska@samsung.com \
    --cc=adilger.kernel@dilger.ca \
    --cc=hch@infradead.org \
    --cc=hughd@google.com \
    --cc=kmpark@infradead.org \
    --cc=kyungmin.park@samsung.com \
    --cc=lczerner@redhat.com \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=sandeen@redhat.com \
    --cc=tim.c.chen@linux.intel.com \
    --cc=tytso@mit.edu \
    /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.