Re: [ANNOUNCE 0/6] Open-iSCSI High-Performance Initiator for Linux

From: Alex Aizman
Date: Wed Mar 09 2005 - 22:00:32 EST


Lars Marowsky-Bree wrote:

On 2005-03-08T22:25:29, Alex Aizman <itn780@xxxxxxxxx> wrote:


There's (or at least was up until today) an ongoing discussion on our mailing list at http://groups-beta.google.com/group/open-iscsi. The short and long of it: the problem can be solved, and it will. Couple simple things we already do: mlockall() to keep the daemon un-swapped, and also looking into potential dependency created by syslog (there's one for 2.4 kernel, not sure if this is an issue for 2.6).



BTW, to get around the very same issues, heartbeat does much the same:
lock itself into memory, reserve a couple of pages more to spare on
stack & heap, run at soft-realtime priority.


Heartbeat is good for reliability, etc. WRT "getting paged-out" - non-deterministic (things depend on time), right?

syslog(), however, sucks.


It does.

We went down the path of using our non-blocking IPC library to have all
our various components log to ha_logd, which then logs to syslog() or
writes to disk or wherever.



Found ha_logd under http://linux-ha.org. The latter is extemely interesting in the longer term. In the short term, there's quite a bit of information on this site, need time.

That works well in our current development series, and if you want to
share code, you can either rip it off (Open Source, we love ya ;) or we
can spin off these parts into a sub-package for you to depend on...



If it's not a big deal :-) let's do the "sub-package" option.

The sfnet is a learning experience; it is by no means a proof that it cannot be done.



I'd also argue that it MUST be done, because the current way of "Oh,
it's somehow related to block stuff, must be in kernel" leads down to
hell. We better figure out good ways around it ;-)


Yes, it MUST be done.


Sincerely,
Lars Marowsky-Brée <lmb@xxxxxxx>



Alex
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/