From inof@pegasus.rz.tu-clausthal.de Fri Apr  2 16:48:45 1999
Return-Path: <inof@pegasus.rz.tu-clausthal.de>
Received: from pegasus.rz.tu-clausthal.de (pegasus.rz.tu-clausthal.de [139.174.2.93])
	by hub.freebsd.org (Postfix) with ESMTP id 600F214E1A
	for <FreeBSD-gnats-submit@freebsd.org>; Fri,  2 Apr 1999 16:48:41 -0800 (PST)
	(envelope-from inof@pegasus.rz.tu-clausthal.de)
Received: (from inof@localhost)
	by pegasus.rz.tu-clausthal.de (8.9.2/8.9.2) id CAA51150;
	Sat, 3 Apr 1999 02:48:22 +0200 (CEST)
	(envelope-from inof)
Message-Id: <199904030048.CAA51150@pegasus.rz.tu-clausthal.de>
Date: Sat, 3 Apr 1999 02:48:22 +0200 (CEST)
From: oliver.fromme@heim3.tu-clausthal.de
Sender: inof@pegasus.rz.tu-clausthal.de
Reply-To: oliver.fromme@heim3.tu-clausthal.de
To: FreeBSD-gnats-submit@freebsd.org
Subject: Bug in UFS/FFS: time / space optimization on large partitions
X-Send-Pr-Version: 3.2

>Number:         10927
>Category:       kern
>Synopsis:       Bug in UFS/FFS: time / space optimization on large partitions
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Fri Apr  2 16:50:01 PST 1999
>Closed-Date:    Sat Apr 3 13:07:19 PST 1999
>Last-Modified:  Sat Apr  3 22:20:01 PST 1999
>Originator:     Oliver Fromme
>Release:        FreeBSD 3.1-19990318-STABLE i386
>Organization:
Clausthal University of Technology
>Environment:

FreeBSD pegasus.rz.tu-clausthal.de 3.1-19990318-STABLE
FreeBSD 3.1-19990318-STABLE #0: Wed Mar 24 19:19:25 CET 1999
inof@pegasus.rz.tu-clausthal.de:/usr/src/sys/compile/PEGASUS
i386

>Description:

We're running a Squid proxy/cache on three large disks (9 Gb
each).  Squid uses them evenly, so all of them have about the
same amount of used space.  Recently we got these kernel
messages:

Apr  1 13:10:53 pegasus /kernel: /var/cache2: optimization changed from TIME to SPACE
Apr  1 14:00:58 pegasus /kernel: /var/cache1: optimization changed from TIME to SPACE
Apr  1 14:30:21 pegasus /kernel: /var/cache3: optimization changed from TIME to SPACE

At that time, the disks were about 35% used.  Unfortunately
I don't have a "df" output from that time for the exact
numbers.  Right now (36 hours later), it looks like this:

Filesystem  1K-blocks     Used    Avail Capacity iused   ifree  %iused  Mounted on
/dev/da1d     8688136  3182309  4810777    40%  208665 1965797    10%   /var/cache1
/dev/da2d     8688136  3180420  4812666    40%  211075 1963387    10%   /var/cache2
/dev/da3d     8688136  3180014  4813072    40%  209630 1964832    10%   /var/cache3

The partitions were _never_ more filled than this.  The amount
of used space has been continually increasing (from 0% to 40%)
since the machine was installed about 10 days ago.  There is
no reason to switch optimization from time to space.
And, in fact, it's rather annoying because the Proxy is quite
busy, and having the FS optimizing for time would be a valuable
advantage.

I suspect that there must be a bug in the 64bit calulations of
the UFS/FFS implementation which decides about the type of
optimization.  Note that the partitions are > 2^31 bytes.

>How-To-Repeat:

Create a large filesystem (> 8 Gb) and start filling it until
about 35%.

>Fix:
	
None known.  :-(


>Release-Note:
>Audit-Trail:

From: Oliver Fromme <oliver.fromme@heim3.tu-clausthal.de>
To: bde@zeta.org.au (Bruce Evans)
Cc: FreeBSD-gnats-submit@FreeBSD.ORG,
	oliver.fromme@heim3.tu-clausthal.de
Subject: Re: kern/10927: Bug in UFS/FFS: time / space optimization on large partitions
Date: Sat, 3 Apr 1999 18:33:00 +0200 (MET DST)

 Bruce Evans wrote:
  > The switch from TIME to SPACE occurs when there are too many fragments.
 
 Oh.  I didn't know that.  I thought it was a function of free
 space on the partition.
 
  > For a filesystem with the default block size of 8K, the default fragment
  > size of 1K, the default minfree of 8%, and the unlikely fragmentation
  > amount of 100%, it occurs when the filesystem is 1/48 (about 2%) full.
  > For a 40% full disk it only takes 5% fragmentation to invoke the switch.
 
 That explains it, indeed:
    212516 files, 3253264 used, 5434872 free
    (451720 frags, 622894 blocks, 5.2% fragmentation)
 
 So the PR can be closed, of course.  Sorry for the confusion.
 I was probably confused by the description in newfs(8), but the
 description in tunefs(8) is more clear.
 
 By the way, what would be better filesystem parameters, in
 order to have optimization for time, as long as possible?
 
 Regards
    Oliver
 
 -- 
 Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany
 (Info: finger userinfo:olli@dorifer.heim3.tu-clausthal.de)
 
 "In jedem Stck Kohle wartet ein Diamant auf seine Geburt"
                                          (Terry Pratchett)
 
State-Changed-From-To: open->closed 
State-Changed-By: steve 
State-Changed-When: Sat Apr 3 13:07:19 PST 1999 
State-Changed-Why:  
Closed at originator's request. 

From: Bruce Evans <bde@zeta.org.au>
To: bde@zeta.org.au, oliver.fromme@heim3.tu-clausthal.de
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: kern/10927: Bug in UFS/FFS: time / space optimization on large partitions
Date: Sun, 4 Apr 1999 16:18:25 +1000

 >So the PR can be closed, of course.  Sorry for the confusion.
 >I was probably confused by the description in newfs(8), but the
 >description in tunefs(8) is more clear.
 
 newfs(8) only describes the initial setting of the flag.  I think
 the initial setting of -o space will get undone on the first allocation
 unless minfree is 0, since there aren't many fragments to begin with.
 
 >By the way, what would be better filesystem parameters, in
 >order to have optimization for time, as long as possible?
 
 Perhaps you want no fragments.  I use a fragment size equal to the
 block size (4K) on some partitions in an attempt to increase efficiency
 by increasing contiguity.
 
 Bruce
 
>Unformatted:
