Path: utzoo!utgpu!watmath!clyde!att!mtunb!jcm
From: jcm@mtunb.ATT.COM (was-John McMillan)
Newsgroups: comp.unix.wizards
Subject: Re: sticky bit
Message-ID: <1359@mtunb.ATT.COM>
Date: 9 Jan 89 17:58:05 GMT
References: <18016@adm.BRL.MIL> <14750@cisunx.UUCP>
Reply-To: jcm@mtunb.UUCP (was-John McMillan)
Organization: AT&T ISL Middletown NJ USA
Lines: 37

In article <14750@cisunx.UUCP> jcbst3@unix.cis.pittsburgh.edu (James C. Benz) writes:
...
>I would like to know if :
>1) this will really help speed things up

	Setting Sticky Bit [SB] ONLY locks programs' SHARED-TEXT images
on the SWAP disk.
	a) It cannot hasten loading of DATA space.
	b) It is UNNECESSARY for programs which typically have another
		incarnation ALREADY RUNNING.
		Ex: It is usually worthless for SH because the user
			typically is already running that program and
			its TEXT is ALREADY on the SWAP disk.
	c) It is irrelevant for TINY programs whose first block and data
		blocks have to be read anyway.

>2) if there are any security problems or potential problems

	A SB-program consumes SWAP SPACE for its TEXT even when it it
	not running.  Therefore, you are that much closer to running out
	of SWAP SPACE -- which is REPORTED as "ENOMEM" -- outta memory --
	when it occurs.

>3) is there a limit to how much can be stored in the swap space (of course!)
>	and is there a way of increasing it if necessary

	Re-defining your partitions/filesystems is little fun if the
	disk is large and your backup media are small :+)

>4) any other dangers like system crashes, lock up, etc you can think of		
	See 2).  Also: each SB-program takes up a TEXT-table entry in
	the kernel -- so re-tuning (NTEXT?) may be appropriate if you're
	doing more than 1 or 2.

First time around, most folk seem to overdo the Sticky-Bit use.

jc mcmillan	-- att!mtunb!jcm	-- muttering for himzelf, only.