botticel@olympus.crd.ge.com (David J. Botticello) (10/03/89)
Well, here is a new one on me, hopefully it is old hat to someone else.
Last week we found the following message on the console of a 3/260 with
64Megs ECC memory, Color Fast-write board, 1x288 SMD disk, 1x327 SCSI
disk, and FPU.
Sept 28 17:21:19 mpsun1 vmunix: /: optimization changed from time to space
We have seen no other trouble/symptoms since. (I know, if it ain't broke
don't fix it...But curiosity has got me on this one)
Any clues???
Dave Botticello - GE CRD - phone(voice) 518-387-6065 Home 518-393-8671
E-mail - botticel@orion.crd.ge.com or uunet!steinmetz!orion!botticel or
botticello@crd.ge.com or botticel%orion@steinmetz.UUCP
land - 1 River Road KWB-1606 Schenectady, N.Y. 12301 tadguy@cs.odu.edu (Tad Guy) (10/05/89)
In article <1917@brazos.Rice.edu> botticel@olympus.crd.ge.com (David J. Botticello) writes:
Well, here is a new one on me, hopefully it is old hat to someone else.
Sept 28 17:21:19 mpsun1 vmunix: /: optimization changed from time to space
Any clues???
In the 4.3BSD ufs_alloc.c:
case FS_OPTTIME:
/*
* At this point we have discovered a file that is trying
* to grow a small fragment to a larger fragment. To save
* time, we allocate a full sized block, then free the
* unused portion. If the file continues to grow, the
* `fragextend' call above will be able to grow it in place
* without further copying. If aberrant programs cause
* disk fragmentation to grow within 2% of the free reserve,
* we choose to begin optimizing for space.
*/
[ generates the ``time to space'' message ]
Likewise, there's also this section:
case FS_OPTSPACE:
/*
* Allocate an exact sized fragment. Although this makes
* best use of space, we will waste time relocating it if
* the file continues to grow. If the fragmentation is
* less than half of the minimum free reserve, we choose
* to begin optimizing for time.
*/
[ generates the ``space to time'' message ]
Looks like you've got some fragmentation going on, probably on a crowded
disk. (Our news spool did this for a while).
...tadpoffen@sj.ate.slb.com (Russ Poffenberger) (10/05/89)
In article <1917@brazos.Rice.edu> botticel@olympus.crd.ge.com (David J. Botticello) writes: >X-Sun-Spots-Digest: Volume 8, Issue 151, message 14 of 15 > >Well, here is a new one on me, hopefully it is old hat to someone else. > >Last week we found the following message on the console of a 3/260 with >64Megs ECC memory, Color Fast-write board, 1x288 SMD disk, 1x327 SCSI >disk, and FPU. > >Sept 28 17:21:19 mpsun1 vmunix: /: optimization changed from time to space > >We have seen no other trouble/symptoms since. (I know, if it ain't broke >don't fix it...But curiosity has got me on this one) > >Any clues??? > I believe what you are seeing is a message related to the organization of your root filesystem. Normally, Sunos reserves 10% of a filesystem for overhead and to prevent the system from becoming tool full and fragmenting. This figure can be changed using the -m switch with newfs. Generally if the value is 10% or greater, the filesystem is optimized for speed of access at a penalty in disk space of course. If this value is <10%, the optimization is for disk space (at a speed penalty). Possibly when the filesystem was created, somebody used this switch to specify <10% free space and when it came close to that threshold, the file system switched. The -o switch on newfs can also be used to override the optimization type. Russ Poffenberger DOMAIN: poffen@sj.ate.slb.com Schlumberger Technologies UUCP: {uunet,decwrl,amdahl}!sjsca4!poffen 1601 Technology Drive CIS: 72401,276 San Jose, Ca. 95110 (408)437-5254