[OpenAFS-devel] suggested feature...

[Neulinger, Nathan]

Assuming CM_DCACHECOUNTFREEPCT*afs_cacheBlocks indicates the minimum amount
of free space that afsd thinks should be free - 

Maybe a call to afs_statfs(afs_cacheSBp,...) to check to see if the amount
of disk space in the cache itself is less than that number, and if so, also
return 1.

That's just an initial guess, I'm not at all sure that would be valid logic.

-- Nathan

> -----Original Message-----
> From: Neulinger, Nathan [mailto:nneul@umr.edu]
> Sent: Tuesday, September 25, 2001 11:00 AM
> Cc: 'openafs-devel@openafs.org'
> Subject: RE: [OpenAFS-devel] suggested feature...
> 
> 
> Looks like this:
> 
> #define afs_CacheIsTooFull() \
>     (afs_blocksUsed - afs_blocksDiscarded > \
>         (CM_DCACHECOUNTFREEPCT*afs_cacheBlocks)/100 || \
>      afs_freeDCCount - afs_discardDCCount < \
>         ((100-CM_DCACHECOUNTFREEPCT)*afs_cacheFiles)/100)
> 
> #define afs_MaybeWakeupTruncateDaemon() \
>     do { \
>         if (!afs_CacheTooFull && afs_CacheIsTooFull()) { \
>             afs_CacheTooFull = 1; \
>             if (!afs_TruncateDaemonRunning) { \
>                 afs_osi_Wakeup((char *)afs_CacheTruncateDaemon); \
>             } \
>         } else if (!afs_TruncateDaemonRunning && \
>                    afs_blocksDiscarded > CM_MAXDISCARDEDCHUNKS) { \
>             afs_osi_Wakeup((char *)afs_CacheTruncateDaemon); \
>         } \
>     } while (0)
> 
> in afs/afs.h is the primary logic of what triggers the 
> truncate daemon.
> (There are several places where those macros are used in 
> afs_dcache.c for
> example. 
> 
> Seems like adjustting afs_CacheIsTooFull() to call a 
> cache-type specific
> routine that can check additional
> usage limits would be enough to get this to work.
> 
> Now just need to figure out a little more of this code to see 
> how to add in
> such a routine, which will most likely be kernel specific, so 
> would likely
> be one of those cases where the routine is a no-op virtually 
> everywhere
> except where it is implemented. (If someone else is much more 
> familiar with
> the internals has any ideas here, please speak up.)
> 
> -- Nathan
> 
> > -----Original Message-----
> > From: Derek Atkins [mailto:warlord@MIT.EDU]
> > Sent: Tuesday, September 25, 2001 10:40 AM
> > To: Neulinger, Nathan
> > Cc: 'openafs-devel@openafs.org'
> > Subject: Re: [OpenAFS-devel] suggested feature...
> > 
> > 
> > Submit a patch. :)
> > 
> > -derek
> > 
> > "Neulinger, Nathan" <nneul@umr.edu> writes:
> > 
> > > > YMMV.
> > > 
> > > Exactly. All the more reason to have it at least handle a 
> > situation where
> > > it's not quite right.
> > > 
> > > -- Nathan
> > > _______________________________________________
> > > OpenAFS-devel mailing list
> > > OpenAFS-devel@openafs.org
> > > https://lists.openafs.org/mailman/listinfo/openafs-devel
> > 
> > -- 
> >        Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
> >        Member, MIT Student Information Processing Board  (SIPB)
> >        URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
> >        warlord@MIT.EDU                        PGP key available
> > 
> _______________________________________________
> OpenAFS-devel mailing list
> OpenAFS-devel@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-devel
>