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. 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/
