public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: "Krzysztof Błaszkowski" <kb@sysmikro.com.pl>
To: Andi Kleen <andi@firstfloor.org>
Cc: xfs@oss.sgi.com
Subject: Re: generating uevents by xfs
Date: Wed, 29 Apr 2009 15:12:33 +0200	[thread overview]
Message-ID: <200904291512.33875.kb@sysmikro.com.pl> (raw)
In-Reply-To: <87r5zbpqsh.fsf@basil.nowhere.org>

On Wednesday 29 April 2009 14:50, Andi Kleen wrote:
> Krzysztof Bâaszkowski <kb@sysmikro.com.pl> writes:
> > Hello,
> >
> > once upon i was asked to think about such facility for notifying
> > userspace when some mount point is nearly full at some level let's say
> > e.g. 90% (threshold should be configurable).
> >
> > here is a solution designed by me and i would like to see comments on
> > this idea and solution.
>
> It doesn't seem to be very useful to poll in kernel for this. When you're
> in kernel you could just hook into the respective functions that handle
> disk allocation directly.

i reckon yes and no both. "no" because i wanted a solution which will have 
almost no impact on performance. if the speed wasn't an important concern 
then why would one take care about per cpu counters like fdblocks ?


> Polling can be as well done in user space only, 
> so it doesn't make too much sense to put polling code into the kernel.

yes i think too, that's maybe a bit too huge thing looking at benefits it 
brings but consider bash instance consuming 1.5M (at least) and other things 
spawned periodically, 
do they have more sense ? i don't think so and this is the solution which 
voids all hassle with userspace polling because it uses unified notification 
system and this can be good starting point for notification system for other 
purposes i haven't think of yet but maybe someone has a new idea regarding 
this.

are these reasons good to (complete and) merge this stuff ?

I found that the xfs-sysfs-2 requires small rework around event_alloc() and 
event_release() because of very rare (but possible) race with timer function 
which drops lock (i decided to drop lock because i think kobject_uevent may 
be synchronous in the case of deprecated /sbin/hotplug and i'm not sure also 
how long it takes for udevd)

i think that there is no point to update patch as long as we will not sort out 
if the whole idea is really worth to implement.

Thanks for reply.

Krzysztof Blaszkowski

>
> -Andi

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

      reply	other threads:[~2009-04-29 13:12 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-28 16:18 generating uevents by xfs Krzysztof Błaszkowski
2009-04-29 12:50 ` Andi Kleen
2009-04-29 13:12   ` Krzysztof Błaszkowski [this message]

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=200904291512.33875.kb@sysmikro.com.pl \
    --to=kb@sysmikro.com.pl \
    --cc=andi@firstfloor.org \
    --cc=xfs@oss.sgi.com \
    /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