Linux-Development-Sys Digest #243, Volume #6 Sat, 9 Jan 99 08:14:16 EST
Contents:
Re: Why I'm dumping Linux, going back to Windblows (Rick)
Re: blocksize / file write speed anomaly (James Youngman)
Re: Why I'm dumping Linux, going back to Windblows (Rick Moen)
Re: (bug fix) Re: 2.2.0-pre5 problem with ip_masq.c ("Harry")
Re: accessing user space memory (Robert Kaiser)
Re: boot problems with 2.2.0-pre5 (Nathan Myers)
Re: klogd problem with new kernels (Nathan Myers)
Re: Registry for Linux - Why? (Frank Sweetser)
Re: Registry for Linux - Bad idea (George MacDonald)
Re: 2.2.0-pre5: Problem with ppp (Nathan Myers)
Re: Open Storage of Application Configuration (was Registry Thread) (Frank Sweetser)
Re: blocksize / file write speed anomaly (libby)
----------------------------------------------------------------------------
From: Rick <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux,comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Why I'm dumping Linux, going back to Windblows
Date: Fri, 08 Jan 1999 15:48:31 -0600
>
> Everytime someone moves away from UNIX/Linux I thank god and tell him
> to keep the morons where they belong!
------------------------------
From: James Youngman <[EMAIL PROTECTED]>
Subject: Re: blocksize / file write speed anomaly
Date: 08 Jan 1999 20:33:44 +0000
Here is the system call profile for the write_linux() function:-
Duration 5 seconds
% time seconds usecs/call calls errors syscall
====== =========== =========== ========= ========= ================
80.14 1.045656 417 2505 write
8.43 0.109945 109945 1 fsync
8.27 0.107868 43 2500 lseek
3.06 0.039945 39945 1 unlink
0.04 0.000529 132 4 1 open
0.02 0.000314 52 6 mmap
0.01 0.000151 50 3 munmap
0.01 0.000097 32 3 close
0.00 0.000051 26 2 fstat
0.00 0.000041 41 1 mprotect
0.00 0.000032 16 2 time
0.00 0.000029 29 1 ioctl
0.00 0.000024 24 1 brk
0.00 0.000018 18 1 personality
0.00 0.000017 17 1 getpid
0.00 0.000017 17 1 1 rmdir
====== =========== =========== ========= ========= ================
100.00 1.304734 5033 2 total
Here is is for the rwrite_linux() function:-
Duration 37 seconds
% time seconds usecs/call calls errors syscall
====== =========== =========== ========= ========= ================
59.83 0.869942 869942 1 fsync
36.82 0.535441 214 2507 write
3.27 0.047601 19 2500 lseek
0.03 0.000372 93 4 1 open
0.02 0.000289 48 6 mmap
0.01 0.000134 45 3 munmap
0.00 0.000072 24 3 close
0.00 0.000045 23 2 fstat
0.00 0.000039 39 1 mprotect
0.00 0.000032 16 2 time
0.00 0.000030 30 1 ioctl
0.00 0.000023 23 1 brk
0.00 0.000018 18 1 personality
0.00 0.000015 15 1 getpid
====== =========== =========== ========= ========= ================
100.00 1.454053 5033 1 total
I added in an extra few printf() calls, which will explain the strange
number of write() calls.
--
ACTUALLY reachable as @free-lunch.demon.(whitehouse)co.uk:james+usenet
------------------------------
From: Rick Moen <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Why I'm dumping Linux, going back to Windblows
Date: 9 Jan 1999 11:02:34 GMT
In comp.os.linux.setup Joseph Coffman <[EMAIL PROTECTED]> wrote:
: vi sucks, and it always has. It should only be used in a
: pinch, or by sadists. Anyone who has room in their head for
: all the vi commands, has probably overwritten some important
: "being human" information in the process of memorizing that
: crap.
Why are you morons still posting this crap across three technical
newsgroups? Grow up. Note followups.
--
Cheers, The cynics among us might say: "We laugh,
Rick Moen monkeyboys -- Linux IS the mainstream UNIX now!
rick (at) linuxmafia.com MuaHaHaHa!" but that would be rude. -- Jim Dennis
------------------------------
From: "Harry" <[EMAIL PROTECTED]>
Subject: Re: (bug fix) Re: 2.2.0-pre5 problem with ip_masq.c
Date: Fri, 8 Jan 1999 21:53:14 +0100
Nathan Myers wrote in message <773ism$4rt$[EMAIL PROTECTED]>...
>Harry<[EMAIL PROTECTED]> wrote:
>>Bryan Franklin wrote in message <771nom$c1a$[EMAIL PROTECTED]>...
>>>I just tried to compile 2.2.0-pre5 with the same options that I compiled
>>>pre4 with and I get the following errors:
>>>ip_masq.c:544: `IP_MASQ_F_DLOOSE' undeclared (first use this function)
>>
>>Putting
>>#define IP_MASQ_F_DLOOSE 0x0010 /* loose dest binding */
>>
>>in include/net/ip_masq.h let me compile the kernel.
>
>... but with wrong results. The -ac1 patch has :
>
>---------------------------------------------------------
>
>--- linux.vanilla/include/net/ip_masq.h Sun Nov 8 15:07:02 1998
>+++ linux.ac/include/net/ip_masq.h Wed Jan 6 23:54:03 1999
>@@ -48,7 +48,8 @@
> #define IP_MASQ_F_NO_SADDR 0x0004 /* no sport set yet */
> #define IP_MASQ_F_NO_SPORT 0x0008 /* no sport set yet */
>
>-#define IP_MASQ_F_NO_REPLY 0x0010 /* no reply yet from
outside */
>+#define IP_MASQ_F_DLOOSE 0x0010 /* loose dest binding */
>+#define IP_MASQ_F_NO_REPLY 0x0080 /* no reply yet from
outside */
>
> #define IP_MASQ_F_HASHED 0x0100 /* hashed entry */
> #define IP_MASQ_F_OUT_SEQ 0x0200 /* must do output seq
adjust */
>
Well it does maquerade, but maybe you're right and I should change
#define IP_MASQ_F_NO_REPLY 0x0080 /* no reply yet from outside
*/
too.
best regards,
--
Raphael Wegmann
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Robert Kaiser)
Subject: Re: accessing user space memory
Date: 9 Jan 1999 10:57:48 GMT
In article <775e77$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Andreas Buschmann) writes:
> [this message is also send to the linux-userfs mailing list.]
>
> I would like to transport the mass data (file contens) through shared
> memory between the kernel, and the userlevel file system server.
> How to do this?
>
> I have would perfer to use the buffers in the userlevel process, which
> will be swapped, if not in use.
>
I have made a patch to do just that :-). It has last been used with
kernel 2.0.33, but I'm pretty confident that it'll work for newer
kernels just as well with little or no modifications.
Have a look at our FTP server: ftp://ftp.sysgeo.de/pub/Linux/
Drop me a mail if you need help using it.
Cheers
Rob
================================================================
Robert Kaiser email: rkaiser AT sysgo DOT de
SYSGO RTS GmbH
Mainz / Germany
------------------------------
From: [EMAIL PROTECTED] (Nathan Myers)
Subject: Re: boot problems with 2.2.0-pre5
Date: 9 Jan 1999 03:42:26 -0800
Frank Hale <[EMAIL PROTECTED]> wrote:
>I just installed the kernel 2.1.132 and patched it too 2.2.0-pre5 then I
>compiled it and installed it and when I boot I get the following
>messages ...
Did you read and follow the instructions in linux/Documentation/Changes?
--
Nathan Myers
[EMAIL PROTECTED] http://www.cantrip.org/
------------------------------
From: [EMAIL PROTECTED] (Nathan Myers)
Subject: Re: klogd problem with new kernels
Date: 9 Jan 1999 03:45:36 -0800
Michael E. Guo<[EMAIL PROTECTED]> wrote:
>I began to use new kernels (2.2.0-pre?) my klogd gives strange messages
>like "Could not find map file" or "Error seeking in /dev/kmem" something
>like that, I've download the source of sysklogd-1.3 from tsx11 but
>cannot compile it with new kernel,
>because it's too old (1996) and many structs has changed in
>linux/module.h. It's the reason that klogd's strange behaviour.
>Is there a updated sysklogd? or any patch to solve this problem?
The answer to this is the same as to all the other questions
about the new kernel: read Documentation/Changes, and follow
the instructions there.
--
Nathan Myers
[EMAIL PROTECTED] http://www.cantrip.org/
------------------------------
From: Frank Sweetser <[EMAIL PROTECTED]>
Subject: Re: Registry for Linux - Why?
Date: 08 Jan 1999 17:45:19 -0500
[EMAIL PROTECTED] (TGAPE!) writes:
> One thing that he didn't say in his response (least, if he did, I missed
> it), is that with so many programs using this data, and possibly
> changing this data, it would be good to have an API so that you have one
> program that handles write access to the file propperly. That is, if it
> needs to write to the file, everyone gets put on hold while it does so.
>
> I've seen cases where that didn't happen, it's not pretty. Especially
> when one of the processes that wants to read in the middle of a write is
> pulling the file in to make its own modifications, and write them back.
> Instant corrupted data.
i'm not sure if it was in the original message, but yes, some kind of
locking has indeed been discussed as being a critical portion of this.
> >wrappers to half a dozen different languages, (or maybe just talk to it via
> >a socket I suppose... but that would REQUIRE networking to be
> >installed...but then.. so does X I guess...)
>
> Ever hear of named pipes? (Pipes always were my special toy...)
>
> On the other hand - so much requires networking these days; it's a
> fairly standard feature. There's also the point that one's
> configuration is a *lot* simpler if one doesn't have networking, this
> wouldn't be nearly as needed.
this would only require networking if you're using a module that required
networking. if all of the apps using the lib only used the flat file
module, then networking should never even be touched.
--
Frank Sweetser rasmusin at wpi.edu fsweetser at blee.net | PGP key available
paramount.ind.wpi.edu RedHat 5.2 kernel 2.2.0pre3 i586 | at public servers
"It's Lois! she's in trouble!"
"Wow, Superman, did you look through that building?"
"Well, kinda.. it's glass."
------------------------------
From: George MacDonald <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Registry for Linux - Bad idea
Date: Fri, 08 Jan 1999 21:47:37 GMT
Frank Sweetser wrote:
>
> George MacDonald <[EMAIL PROTECTED]> writes:
>
> > > > Maybe it should be store.conf or opStore.conf, hmm
> > > >
> > > > Thoughts?
> > >
> > > it should definatelly be a directory, /etc/appconf.d/ a lot of the redhat
> > > systems have been doing this for packages like pam and logrotate. any app
> > > that wants to interface with either of them simply places it's own config
> > > file in the appropriate /etc/ subdir, and the package picks it up and runs
> > > with it. so to get logrotate to work on your custom data file, you simply
> > > need to create /etc/logrotate.d/mylogfile and logrotate will use it. much
> > > easier to use (and esp to automate!!) than having a single config file with
> > > multiple sections.
> >
> > Nice solution! That handles the new conventions on linux perfectly.
> > Linux seems a bit more organized and better thought out than other
> > unix implementations, well at least with regards to configuration.
>
> thought about this a bit more, including how it might fit in with the
> precedence issue. we should be able to simplify this into 4 main layers.
>
> 1 - global policies. these would be organization wide policies, nearly
> always coming in from a centralized server in one fashion or another.
>
> 2 - system policies. these are policies that apply only to the local host
> - file locations, resources availible, etc.
>
> 3 - user policies. these are the ones that the user has control of,
> typically stored in a ~/.foo directory.
>
> 4 - applications defaults - whatever the compiled in defaults for that
> particular application are.
>
More good stuff!! I think 1. might be a bit more complicated, i.e. departmental
policy, division policy, ... So perhaps, if possible, allow for a
"policy hierarchy". But for sake of discussion the above example is fine.
In reality organizations are both hierarchical and flat, and also have
simultaneous combinations, in other words they are complex. Allowing
an accurate reflection of desired policies will also be complex.
> global policies would be ones that universally apply to everyone in the
> organization - such as the organization name, network configuration
> information (for a sufficiently simply network), etc. most of these would
> be marked as non-overridable. system policies would be ones dictated by
> the administrator of that particular machine that may or may not apply to
> other machines. first thing that comes to mind here would be local file
> locations.
>
Yep! Well some of the policy on any particular machine may be dictated
by one or more external(to that machine) sources. This would have to be refelected in
a secure location that cannot be overriden by users on a machine. i.e. file
owned by root.
> user polices are whatever the user has configured in their own private
> configuration, and app defaults is exactly that - whatever default settings
> the app ships with. hmm... this should also include /etc/opStore/<appname>
> - this could allow the application to generate system wide defaults
> settings at install time.
>
> the top layers should have locations to define metadata, say,
> /etc/opStore.d/opStore for the global and system,
> /etc/opStore.d/<application> for the application level, and
> ~/opStore/defaults for the user level. assume that the levels are
> consulted internally as listed above, 1 - 4. if an option is specified
> multiple times, each time will overwrite the previous one, unless one of
> the previous specifications has marked the options as immutable. each
> level would be able to specify the exact locations/methods of where and how
> to get it's resources, and what order *they* should be consulted in.
>
> overall, this should result in a level of configurability that's just plain
> silly =)
Outrageously so! ROFL
>
> > I would like one file that is higher up than than appconf.d that
> > allows the location of appconf.d to be configured. My reasoning is that
> > on other unix's the /etc area is in root is sometimes quite small, so may
> > not be capabable of holding it. I can envisage other systems
> > wanting to put the "appconf.d" directory in /usr/lib or usr/share,
> > ... I kind of like the linux way, but perhaps we should allow for
> > the placement elsewhere.
>
> definatelly. all we really need to find is a single metadata config file,
> which can then contain pointers to everything else.
>
Maybe eventually /etc/sysconfig/stores, but for now /etc/openStore.conf
--
We stand on the shoulders of those giants who coded before.
Build a good layer, stand strong, and prepare for the next wave.
Guide those who come after you, give them your shoulder, lend them your code.
Code well and live! - [EMAIL PROTECTED] (7th Coding Battalion)
------------------------------
From: [EMAIL PROTECTED] (Nathan Myers)
Subject: Re: 2.2.0-pre5: Problem with ppp
Date: 9 Jan 1999 03:39:43 -0800
Michael Keller <[EMAIL PROTECTED]> wrote:
>I just compiled the Kernel 2.2.0-pre5 on my S.u.S.E. 5.3 installation
>successfully.
>Booting with it, my ppp connection behaves as follows:
> ...
>What can I do?
Read /usr/src/linux/Documentation/Changes. Make sure your
utilities are up to date. Compare the versions of what you
have (typically available with the "-v" option, but check
the man pages). You may need a new pppd, or a new set of
net utilities. If you don't feel good about getting the
source and recompiling them (why not?) then wait around
for Suse 6.0 next month.
--
Nathan Myers
[EMAIL PROTECTED] http://www.cantrip.org/
------------------------------
From: Frank Sweetser <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Open Storage of Application Configuration (was Registry Thread)
Date: 08 Jan 1999 18:49:44 -0500
George MacDonald <[EMAIL PROTECTED]> writes:
> > The ".d" looks like a naming convention used to distiguish between a
> > file and a directory that would otherwise bear the same name. I think
> > the first use was simply to note the distinction between
> >
> > /etc/rc and a directory that was replacing it
> >
> > Red Hat seems to have used it also for /etc/logrotate.d ,
> > /etc/profile.d and /etc/pam.d
> >
> > Was there a /etc/logrotate or a /etc/pam before?
yup. there's still an /etc/pam.conf, but it's only for backwards
compatability, and includes a comment pointing to /etc/pam.d/
> > Well it doesn't much matter to me, a /etc/opStore or /etc/opStore.d
> > is fine. I would like to have the /etc/opStore.conf though.
> >
> > Also longer term I was thinking of defining other "stores" i.e
> >
> > opStore
> > |
> > |
> > V
> > OpenStore = UserStore + AppStore + SystemStore + NetStore ( + otherStores)
> >
> > Where the UserStore is user specific, System store handles system
> > related info(hostname info, passwd, file system, ...)
> > AppStore handles the application specific info(i.e. default settings),
> > NetStore handles things stored on the network.
> >
> > The UsersStore has it's own data, pulls in data from the other stores,
> > and/or defines "views" into the other stores to define how to get the data.
> > The various stores would be configured in the /etc/opStore.conf file.
hmm... sounds like we were thinking basically the same thing - i defined it
in terms of configurating levels within the main config file, while you're
talking about coding up distinct, integrated packages. correct?
> > i.e.
> >
> > AppStore: /usr/etc/AppStore
> >
> > or
> >
> > AppStore: /usr/local/lib/AppStore
> >
> > B.t.w. I just checked with the companay that uses the name
> www.openstore.com
> > and they said it was ok if we wanted to use www.openstore.org! So I
> > was thinking of expanding the name to OpenStore. What do you think?
works for me =)
> > I think Frank is correct in puting the "configuration about where to get
> > the application configuration info" in /etc/opStore.d . I would also
> > like to allow the definition of macros in opStore.conf that can
> > be used in the /etc/opStore.d files. For example it would be nice to
> > define common "switch" settings, perhaps to define a "mobile",
> > "dockedAtHome", "dockedAtWork" macros that define
> > the "how to find config info" settings for each of those contexts.
> >
>
> Hmm. that's not quite right. Information on how a "store" in general
> gets its data is Meta data about the store. It's more like a list
> of access methods or mechanisms, pehaps a list of possible methods,
> then a list of ordered method lists. This is getting kind of lispy,
> I can see why gnome is scheme'ified.
blech... never could really wrap my mind around lisp. i think part of it
is just the visually ugly and non eye-friendly syntax, though....
> So each store can have a default access list, i.e. for that store
> the default order in which information is retrieved. These of
> course can then be overriden by each type/class of object in
> it's store, and then also by each instance. Hmm, yeah that
> sounds better.
>
> So each instance of a variable has an evaluation tree that
> is processed to determine it's value. Thus to determine the
> value, start at the head, then evaluate each "node" in a
> breadth first, ordered manner, until the evaluation is
> complete(i.e. obtains the desired value). What we have been
> talking about is how to define the evaluation tree.
>
> The depth and breadth of the evaluation tree can be as
> large as is needed. i.e. a local flat file is
>
> depth=1, breadth=1
>
> fetching the value from an application default, using a RDBMS
> might be at node
>
> depth=2, breadth=2
>
>
> Sorry, this is a bit abstract and I am kind of thinking out
> loud. Does this make sense?
makes perfect sense to me. to elaborate (if i'm correct =) a typicall tree
might look like this (forgive the long lines....)
start here
|
|
|
V
global ---> RDBMS on central company server
config |
|
V
system ---> RDBMS on central server --> local file, ------> local file,
config | keyed on machine name /etc/opStore.d/defaults opStore/<app>
|
V
user ---> RDBMS on central server --> local file, ----> local file,
config | keyed on user name ~/.opStore/defaults ~/.opStore/<app>
|
V
app ---> compiled in defaults
config
--
Frank Sweetser rasmusin at wpi.edu fsweetser at blee.net | PGP key available
paramount.ind.wpi.edu RedHat 5.2 kernel 2.2.0pre3 i586 | at public servers
"It's Lois! she's in trouble!"
"Wow, Superman, did you look through that building?"
"Well, kinda.. it's glass."
------------------------------
From: libby <[EMAIL PROTECTED]>
Subject: Re: blocksize / file write speed anomaly
Date: Fri, 08 Jan 1999 23:59:03 +0000
I originally wrote my test program with fdatasync and I got the same (bad) results.
Also ,
I need to be sure the inode entries are updated at that time.
Also , I am still wondering if anybody out there knows under what conditions Linux
will read
the block before writing the block on a random write. I do not think it should as long
as you
write to a 512 byte ( sector) boundary but that does appear to be what is happening.
Paul Popowski wrote:
> If you look where the bottleneck in your program occurs it's at the point where you
>call
> fsync.
> The man page for fsync even acknowledges that for some applications the function
>fdatasync
> would
> be a better choice. Running your program with fsync (in the random write) changed to
> fdatasync I get
> the exact same results as the first part of the test actually even better in some
>cases.
>
> pops
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and comp.os.linux.development.system) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Development-System Digest
******************************
