Hi, On Wed, Jan 06, 2010 at 05:13:16PM +0100, Lars Ellenberg wrote: > On Wed, Jan 06, 2010 at 04:55:23PM +0100, Lars Marowsky-Bree wrote: > > On 2010-01-06T16:32:33, Dejan Muhamedagic <[email protected]> wrote: > > > > > > That said, I'm fine with using a file if it keeps up the performance. > > > > But the sync_script - we definitely don't want to be calling an external > > > > script, I guess. csync2 would be automatic anyway. > > > > > > The script (or program) is invoked once in a while on monitor, > > > shouldn't be a performance issue. > > > > It's invoked every time, and to keep the connection table reasonably > > uptodate, I guess monitor would be scheduled fairly frequently. > > again. > we don't need to be perfect. > "reasonably" here depends very much on the type of connection. > my rationale is, if you have short lived connections, changing all the > time, you don't need tickles anyways.
Right. Let's not lose touch with reality :) Cheers, Dejan > web clients don't benefit from tickle acks. > the user will click on reload anyways pretty fast. > > iSCSI initiators will probably benefit a lot. > > if you have long living connections, you typically have a stable > connection table as well. > > so monitoring once a minute is fine. > > the occasional missed connection is bad luck, but will simply have to > recognize the connection loss by itself as it is now. > > all other connections, which is most, get the benefit of tickles, > thus earlier notice of the need to re-establish the connection. > > > So yes, this is costly, the question is whether it is still good enough > > absolutely good enough. > > > > > Oh. This is quite costly, is it not? Scanning the full TCP connection > > > > table and regenerating the whole lease-file? > > > Looking again at it, egrep and while loop could be replaced by a > > > perl/awk/python snippet. Then it should be fast enough. > > > > We're looking at scanning potentially thousands of connections here, > > which a busy file server might easily have. There's not just the > > processing overhead in user-space, but also the overhead of retrieving > > the information from the kernel, and I doubt that that is extremly fast. > > Worse, scanning those tables might even incur an in-kernel penalty due > > to data structure locking. > > > > But that's just a gut feeling, I'd be happy to see some numbers. > > then produce some. > I'm sure you have access to some pretty busy file servers, > and you are able to type "time netstat -t4n | wc -l" > > if that takes less than about a second, we are fine, as I think > monitoring once or twice a minute is absolutely ok. > > > > > How is this done in Samba? > > well, it is simply integrated into the daemon. > after all, the daemon knows best who it is talking to. > > this approach is to improve the situation for those daemons > that can benefit from tickle acks (long living, but still timing > critical, connections, like iSCSI), but where it is unlikely > that such functionality will be added soonish. > > > I'm not saying the current approach is bad, I just want to understand > > why it is good enough ;-) > > because it improves the current situation, without much effort > (apart from the effort Jiaju Zhang put into it - thanks again!) > > > -- > : Lars Ellenberg > : LINBIT | Your Way to High Availability > : DRBD/HA support and consulting http://www.linbit.com > > DRBD® and LINBIT® are registered trademarks of LINBIT, Austria. > _______________________________________________________ > Linux-HA-Dev: [email protected] > http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev > Home Page: http://linux-ha.org/ _______________________________________________________ Linux-HA-Dev: [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
