On Wed, 1 Sep 1999, Mike Smith wrote:
> No. Try for a patch that guesses how big the password file is (try
> using stat()) and tunes the cache dynamically.
>
> Hardcoding this at _build_ time is not any sort of "right" solution.
Agreed on all counts. I'd also like to add a vote for thi
On Wed, 1 Sep 1999, Mike Smith wrote:
> No. Try for a patch that guesses how big the password file is (try
> using stat()) and tunes the cache dynamically.
>
> Hardcoding this at _build_ time is not any sort of "right" solution.
Agreed on all counts. I'd also like to add a vote for th
>
> Why is it OK for top to do it, but not pwd_mkdb? I probably end up
> updating my OS faster than I add users to my password file...
Top being wrong is not a justification for doing it wrong again.
> Tweak the cache to 32MB's, and never touch it again, regardless of how big
> your passwd file
>
> Why is it OK for top to do it, but not pwd_mkdb? I probably end up
> updating my OS faster than I add users to my password file...
Top being wrong is not a justification for doing it wrong again.
> Tweak the cache to 32MB's, and never touch it again, regardless of how big
> your passwd fil
On Wed, 01 Sep 1999 02:08:59 MST, Jaye Mathisen wrote:
> But I'm not saying change the default, leave it at 2, I just think
> it should be easy to tweak, such that it is persistent across source
> updates.
I think what both Mike and I are suggesting is that a magic value for
which the ideal set
On Wed, 01 Sep 1999 01:05:40 MST, Jaye Mathisen wrote:
> Why is it OK for top to do it, but not pwd_mkdb? I probably end up
> updating my OS faster than I add users to my password file...
I think that's the wrong question. I think the right question is
Is it okay to adhere to the low
On Wed, 01 Sep 1999 02:08:59 MST, Jaye Mathisen wrote:
> But I'm not saying change the default, leave it at 2, I just think
> it should be easy to tweak, such that it is persistent across source
> updates.
I think what both Mike and I are suggesting is that a magic value for
which the ideal se
Why is it OK for top to do it, but not pwd_mkdb? I probably end up
updating my OS faster than I add users to my password file...
Tweak the cache to 32MB's, and never touch it again, regardless of how big
your passwd file is...
On Wed, 1 Sep 1999, Mike Smith wrote:
> >
> >
> > Got tired of th
>
>
> Got tired of the dinky cachesize for pwd_mkdb, especially since vipw
> doesn't take advantage of the -u or -s options.
>
> So here a couple patches that make the cachesize tweakable from make.conf.
>
> Dramatically helps on those 10-15k line password files.
>
> I would appreciate it if s
Well, in my case, changing from 2MB to 8MB's knocked the rebuild time from
2:05 to 36 seconds, for appx 15000 records.
not enough memory to make a real difference that I can see, but it kept
the disk tps meter pegged at 118-120.
On Wed, 1 Sep 1999, Sheldon Hearn wrote:
>
>
> On Tue, 31 Aug 19
On Tue, 31 Aug 1999 18:29:58 MST, Jaye Mathisen wrote:
> Got tired of the dinky cachesize for pwd_mkdb, especially since vipw
> doesn't take advantage of the -u or -s options.
Vipw doesn't take advantage of the -u option? I must have read through
the code too fast.
> Dramatically helps on thos
On Wed, 01 Sep 1999 01:05:40 MST, Jaye Mathisen wrote:
> Why is it OK for top to do it, but not pwd_mkdb? I probably end up
> updating my OS faster than I add users to my password file...
I think that's the wrong question. I think the right question is
Is it okay to adhere to the lo
Why is it OK for top to do it, but not pwd_mkdb? I probably end up
updating my OS faster than I add users to my password file...
Tweak the cache to 32MB's, and never touch it again, regardless of how big
your passwd file is...
On Wed, 1 Sep 1999, Mike Smith wrote:
> >
> >
> > Got tired of t
>
>
> Got tired of the dinky cachesize for pwd_mkdb, especially since vipw
> doesn't take advantage of the -u or -s options.
>
> So here a couple patches that make the cachesize tweakable from make.conf.
>
> Dramatically helps on those 10-15k line password files.
>
> I would appreciate it if
Well, in my case, changing from 2MB to 8MB's knocked the rebuild time from
2:05 to 36 seconds, for appx 15000 records.
not enough memory to make a real difference that I can see, but it kept
the disk tps meter pegged at 118-120.
On Wed, 1 Sep 1999, Sheldon Hearn wrote:
>
>
> On Tue, 31 Aug 1
On Tue, 31 Aug 1999 18:29:58 MST, Jaye Mathisen wrote:
> Got tired of the dinky cachesize for pwd_mkdb, especially since vipw
> doesn't take advantage of the -u or -s options.
Vipw doesn't take advantage of the -u option? I must have read through
the code too fast.
> Dramatically helps on tho
Got tired of the dinky cachesize for pwd_mkdb, especially since vipw
doesn't take advantage of the -u or -s options.
So here a couple patches that make the cachesize tweakable from make.conf.
Dramatically helps on those 10-15k line password files.
I would appreciate it if somebody would at lea
Got tired of the dinky cachesize for pwd_mkdb, especially since vipw
doesn't take advantage of the -u or -s options.
So here a couple patches that make the cachesize tweakable from make.conf.
Dramatically helps on those 10-15k line password files.
I would appreciate it if somebody would at le
18 matches
Mail list logo
