[Top] [All Lists]

Re: generating uevents by xfs

To: Andi Kleen <andi@xxxxxxxxxxxxxx>
Subject: Re: generating uevents by xfs
From: Krzysztof Błaszkowski <kb@xxxxxxxxxxxxxxx>
Date: Wed, 29 Apr 2009 15:12:33 +0200
Cc: xfs@xxxxxxxxxxx
In-reply-to: <87r5zbpqsh.fsf@xxxxxxxxxxxxxxxxx>
Organization: Systemy mikroprocesorowe
References: <200904281818.32127.kb@xxxxxxxxxxxxxxx> <87r5zbpqsh.fsf@xxxxxxxxxxxxxxxxx>
User-agent: KMail/1.9.5
On Wednesday 29 April 2009 14:50, Andi Kleen wrote:
> Krzysztof Bâaszkowski <kb@xxxxxxxxxxxxxxx> 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 

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

<Prev in Thread] Current Thread [Next in Thread>