[OpenAFS-devel] PATCH: limit afsd auto-tuning to 500000 files
Troy Benjegerdes
hozer@hozed.org
Tue, 23 Aug 2005 22:41:46 -0500
This is a MIME-formatted message. If you see this text it means that your
E-mail software does not support MIME-formatted messages.
--=_kalmia.hozed.org-3120-1124854906-0001-2
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
On Tue, Aug 23, 2005 at 08:56:39PM -0400, Jeffrey Hutzelman wrote:
>
>
> On Tuesday, August 23, 2005 08:23:13 PM -0400 chas williams - CONTRACTOR
> <chas@cmf.nrl.navy.mil> wrote:
>
> >In message <475D0B15E1CC68BBF87A7B2D@sirius.fac.cs.cmu.edu>,Jeffrey
> >Hutzelman writes:
> >>67%-full assumption is incorrect. Perhaps we were too conservative in
> >>bumping the average filesize assumption from 10K to 32K, and it should
> >>really be bigger.
> >
> >i dont believe that there should be linear relationsip between the
> >average filesize and the cache size. when a user increases the disk
> >cache, the more kernel memory is not available.
>
> Well, right now we use two numbers. One is a constant; the other is a
> function of the chunk size. It sounds like you're arguing for eliminating
> the constant, or at least limiting its effect as the cache size grows very
> large. Fine, but without data, how do we decide where to draw the line?
> With a small cache and a large chunk size, we need that constant to ensure
> we have enough files.
What happens when we run out of files? Is my math on 500K files * 1MB
chunksize == 500GB cache right?
We can talk about average file size all we want, but until we have a
bunch of people with stats actually using really huge caches, I don't
think we'll know. The attached patch also modifies 'fs getacheparms' to
return the following:
>fs getcacheparms
AFS using 64% of cache blocks (12751138 of 20000000 1k blocks)
2% of the cache files (8242 of 500000 files)
With the default tuning file limit of 500k, or 1M or whatever you want,
we will at least give reasonable defaults if someone uses a much larger
cache than they need. They will only waste disk space. And when you have
an OS image that takes 4G and the smallest disk you can order has 40G,
that's really just not an issue. If the file limit becomes an issue,
users can easily just say 'afsd -files 100000000' if they really want.
While we're talking about chunksizes, does having afs_FirstCSize be a
different chunksize than afs_OtherCsize actually work? It looks like
they get initially assigned to the same value.
--=_kalmia.hozed.org-3120-1124854906-0001-2
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename=afs-cache-diff
Index: src/afs/afs_pioctl.c
===================================================================
RCS file: /cvs/openafs/src/afs/afs_pioctl.c,v
retrieving revision 1.102
diff -u -r1.102 afs_pioctl.c
--- src/afs/afs_pioctl.c 28 Jul 2005 14:38:36 -0000 1.102
+++ src/afs/afs_pioctl.c 24 Aug 2005 03:32:11 -0000
@@ -2154,11 +2154,20 @@
DECL_PIOCTL(PGetCacheSize)
{
afs_int32 results[MAXGCSTATS];
-
+ afs_int32 afs_cacheFilesUsed = 0;
+ int i;
+
+ for (i = 0; i < afs_cacheFiles; i++) {
+ if (afs_indexFlags[i] & IFEverUsed)
+ afs_cacheFilesUsed++;
+ }
+
AFS_STATCNT(PGetCacheSize);
memset((char *)results, 0, sizeof(results));
results[0] = afs_cacheBlocks;
results[1] = afs_blocksUsed;
+ results[2] = afs_cacheFiles;
+ results[3] = afs_cacheFilesUsed;
memcpy(aout, (char *)results, sizeof(results));
*aoutSize = sizeof(results);
return 0;
Index: src/afsd/afsd.c
===================================================================
RCS file: /cvs/openafs/src/afsd/afsd.c,v
retrieving revision 1.55
diff -u -r1.55 afsd.c
--- src/afsd/afsd.c 17 Aug 2005 16:16:50 -0000 1.55
+++ src/afsd/afsd.c 24 Aug 2005 03:32:12 -0000
@@ -1689,7 +1689,13 @@
if (cacheFiles < 100)
fprintf(stderr, "%s: WARNING: cache probably too small!\n",
rn);
-
+
+#define MAXFILES 500000
+ if (cacheFiles > MAXFILES){
+ fprintf(stderr, "%s: WARNING: cacheFiles was %d\n", rn, cacheFiles);
+ fprintf(stderr, " limiting to %d\n", MAXFILES);
+ cacheFiles = MAXFILES;
+ }
if (afsd_verbose)
printf("%s: cacheFiles autotuned to %d\n", rn, cacheFiles);
}
@@ -2387,7 +2393,7 @@
syscall(AFS_SYSCALL, AFSCALL_CALL, param1, param2, param3, param4,
param5, param6, param7);
- if (afsd_verbose)
+ if (afsd_debug)
printf("SScall(%d, %d, %d)=%d ", AFS_SYSCALL, AFSCALL_CALL, param1,
error);
return (error);
Index: src/venus/fs.c
===================================================================
RCS file: /cvs/openafs/src/venus/fs.c,v
retrieving revision 1.28
diff -u -r1.28 fs.c
--- src/venus/fs.c 24 Jun 2005 02:54:13 -0000 1.28
+++ src/venus/fs.c 24 Aug 2005 03:32:14 -0000
@@ -1208,7 +1208,7 @@
struct vcxstat2 stat;
blob.out_size = sizeof(struct vcxstat2);
blob.in_size = 0;
- blob.out = &stat;
+ blob.out = (void *)&stat;
code = pioctl(ti->data, VIOC_GETVCXSTATUS2, &blob, 1);
if (code) {
Die(errno, ti->data);
@@ -2009,6 +2009,7 @@
afs_int32 code;
struct ViceIoctl blob;
afs_int32 parms[MAXGCSIZE];
+ double percent;
memset(parms, '\0', sizeof parms); /* avoid Purify UMR error */
blob.in = NULL;
@@ -2020,11 +2021,15 @@
Die(errno, NULL);
return 1;
}
- printf("AFS using %d of the cache's available %d 1K byte blocks.\n",
- parms[1], parms[0]);
+ percent = ((double)parms[1]/parms[0]) * 100;
+ printf("AFS using %5.0f%% of cache blocks (%d of %d 1k blocks)\n",
+ percent, parms[1], parms[0]);
if (parms[1] > parms[0])
printf
("[Cache guideline temporarily deliberately exceeded; it will be adjusted down but you may wish to increase the cache size.]\n");
+ percent = ((double)parms[3]/parms[2]) * 100;
+ printf(" %5.0f%% of the cache files (%d of %d files)\n",
+ percent, parms[3], parms[2]);
return 0;
}
--=_kalmia.hozed.org-3120-1124854906-0001-2--