I'm what you'd call good at NSS. But NSS on OES2 is another critter. This session took us through the updates. From my notes:
- Three times the NSS source tree has been accidentally deleted by developers. It has been restored from Salvage each time. Go Salvage.
- When mounting NSS on OES-Linux, mount it with the long namespace. Saves time. I did not catch the fstab option to make this work, though.
- You can create NSS pools that are not NetWare compatible
- NSS & LUM
- NSS = 128-bit, Unix = 32-bit. LUM handles the translations.
- Users need to be LUM-enabled for this to work
- NCP-Serv can fake it for non-LUM users, but it is slower access.
- OES1 = Rights and owners set all posix
- OES2 = Rights and owners set through extended attributes
- If Samba, then LUM.
- Trustees are enforced, GUID is ignored.
- Beasts = inodes!
- /proc/slabinfo -> lsa_inode_cache = @ of inodes/files in cache
- On NetWare, memory over the 4GB line is treated as a RAMdisk for files over 128K in size.
- 32-bit vs 64-bit linux & NSS
- 32-bit linux: 1GB max kernel memory, makes for tricky caching
- 64-bit linux: All memory can be kernel memory
- NSS patch in mid-December allowed meta-data caching in user-memory, greatly speeding up meta-data reads on 32-bit systems with large numbers of files.
- nss /HighMemoryCacheType= [private|linux|none]
- Sets the use of User memory in 32-bit OES
- None = Use the same algorithm as OES-FCS, which is to try and cache everything in Kernel-mode memory. Only option on 64-bit linux since it doesn't have to use USER memory at all.
- linux = integrate caching into the regular linux caches. This can be a problem on dual use file-server/app-server system, as memory hungry applications can cause the file-system cache to purge completely.
- private = set up a separate user-mode cache in memory outside of the linux cache. Best for dedicated file-servers.