| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 8971.1 | sparse files | NETRIX::"[email protected]" | Farrell Woods | Wed Feb 26 1997 10:42 | 12 |
| Though I can't explain the exact numbers you're seeing, I do know that
the dbm routines that NIS uses create sparse files. That is, the actual
amount of space that the file occupies does not correspond to what
an "ls -l" of that file tells you.
Have the customer do a "df" both before and after the makedbm to see how
much space is actually taken by the maps.
-- Farrell
[Posted by WWW Notes gateway]
|
| 8971.2 | | VAXCPU::michaud | Jeff Michaud - ObjectBroker | Wed Feb 26 1997 11:32 | 5 |
| > Have the customer do a "df" both before and after the makedbm to see how
> much space is actually taken by the maps.
Even easier, use "du" on the file to see how much disk space is
really being occupied by the file.
|
| 8971.3 | Digital UNIX doesn't like large DBM files | ZEKE::ranger.zko.dec.com::dilsworth | Keith Dilsworth | Wed Feb 26 1997 12:58 | 6 |
| This sounds simular to the bug with mkpasswd. There are some
problems with the dbm library routines on Digital UNIX.
I had a 59000 user passwd file that would fail after mkpasswd
processed 31,520 entries. I was able to get mkpasswd to work by
shortening the user description fields for the passwd entries.
|
| 8971.4 | did makedbm complain? | NETRIX::"[email protected]" | Farrell Woods | Wed Feb 26 1997 15:10 | 14 |
| .3 brings up a question about .0: did makedbm complain? That is did you
see a message like "problem storing foo foo:mI83gEvb..."
Fwiw, the libc folks have a new interface for ndbm that will allow the
size of the page buffer to be adjusted. Right now it's fixed at 1024
bytes. We're getting more reports of folks who are trying to build big
NIS maps and are bumping into limits imposed by the current ndbm functions.
This will be addressed for Steel.
-- Farrell
[Posted by WWW Notes gateway]
|
| 8971.5 | Makedbm complained. | NETRIX::"[email protected]" | Thomas Sjolshagen | Thu Feb 27 1997 02:08 | 21 |
| Hi,
Thanks for the replies so far..
Re 1. : Is NIS actually able to copy the sparse files 'correctly' ie,
so they don't take up all the space that 'ls' claims they do. (ref.
if you do a cp of wtmp it _will_ take up the space listed by 'ls -l')
Re .3 : Not sure I have the guts to tell our customer that, but unless
there's another solution, I guess I don't have much of a choice.
Not something I wanna suggest as a 'maybe it'll fix it'.... :)
Re .4 : Saw the 'problem storing' message yes. Is this an issue of
the number of passwd entries, or the size of the passwd file itself??
Thanks again for the replies!
-- Thomas
[Posted by WWW Notes gateway]
|
| 8971.6 | | ZEKE::ranger.zko.dec.com::dilsworth | Keith Dilsworth | Mon Mar 03 1997 13:49 | 16 |
| re .4
Yes, mkpasswd complained with "mkpasswd: dbm_store failed: File
too large" See note 5590.x I did get a statically built mkpasswd
that used the patched dbm librarires and a 2048 buffer size. It
would run with my passwd file and the user could login. ls -l would
core dump trying to get the owner of a file from the passwd files.
Unfortunantly, the fix isn't a simple replacement of mkpasswd. The
total fix will be in the steel release.
re .5
Perl was also failing with "Out of memory" with large internal dbm
hash arrays. We built a perl with the fixed dbm libraries and the
problem went away. There is a bug in the dbm libraries that will
effect anything that tries to make a very large dbm file using the
libraries.
|