[122] in The Cryptographic File System users list
Re: Memory usage on large encrypted volumes
daemon@ATHENA.MIT.EDU (Rob Stampfli)
Mon Jan 25 23:41:41 1999
From owner-cfs-users@research.att.com Tue Jan 26 04:41:40 1999
Return-Path: <owner-cfs-users@research.att.com>
Delivered-To: cfs-mtg@bloom-picayune.mit.edu
Received: (qmail 27191 invoked from network); 26 Jan 1999 04:41:38 -0000
Received: from unknown (HELO mail-blue.research.att.com) (135.207.30.102)
by bloom-picayune.mit.edu with SMTP; 26 Jan 1999 04:41:38 -0000
Received: from amontillado.research.att.com (amontillado.research.att.com [135.207.24.32])
by mail-blue.research.att.com (Postfix) with ESMTP
id B653F4CE41; Mon, 25 Jan 1999 23:41:37 -0500 (EST)
Received: from nsa.research.att.com (majordomo@nsa.research.att.com [135.207.24.155])
by amontillado.research.att.com (8.8.7/8.8.7) with ESMTP id XAA20839;
Mon, 25 Jan 1999 23:41:33 -0500 (EST)
Received: (from majordomo@localhost) by nsa.research.att.com (8.7.3/8.7.3) id XAA01436 for cfs-users-list; Mon, 25 Jan 1999 23:40:07 -0500 (EST)
X-Authentication-Warning: nsa.research.att.com: majordomo set sender to owner-cfs-users@nsa.research.att.com using -f
Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by nsa.research.att.com (8.7.3/8.7.3) with ESMTP id XAA01432 for <cfs-users@nsa.research.att.com>; Mon, 25 Jan 1999 23:40:05 -0500 (EST)
Delivered-To: cfs-users@research.att.com
Received: from elektro.cmhnet.org (elektro.com [192.188.133.3])
by mail-blue.research.att.com (Postfix) with ESMTP
id 1DA3B4CE20; Mon, 25 Jan 1999 23:41:11 -0500 (EST)
Received: from colnet (2054 bytes) by elektro.cmhnet.org
via sendmail with P:uucp/R:inet_hosts/T:smtp
(sender: <colnet!res>)
id <m1050Ik-0008ArC@elektro.cmhnet.org>
for research.att.com!cfs-users; Mon, 25 Jan 1999 23:40:34 -0500 (EST)
(Smail-3.2.0.103 1998-Oct-9 #1 built 1998-Dec-13)
Received: by colnet.cmhnet.org (Smail3.1.28.1 #4)
id m1050GM-0008F6C; Mon, 25 Jan 99 23:38 EST
Message-Id: <m1050GM-0008F6C@colnet.cmhnet.org>
Date: Mon, 25 Jan 99 23:38 EST
From: res@colnet.cmhnet.org (Rob Stampfli)
To: cfs-users@research.att.com
Subject: Re: Memory usage on large encrypted volumes
Sender: owner-cfs-users@research.att.com
Precedence: bulk
In recent email Matt writes:
>
>Yes, unfortunately CFS does badly with very large (in terms of
>number of files) file systems. This is because it keeps the
>inode table in memory, and has no way to garbage collect as long
>as a directory is attached (since you might reference a handle
>that was given out long ago).
Just a comment, although it may not be a solution to the original poster:
I've noticed that cfsd becomes less reliable as it becomes a very-big-
process -- exhibiting increasingly "glitchy" behavior -- and that it
occasionally fails catastrophically when it grows to be truly humongous.
This may be a problem with my malloc() library (SunOS 4.1.4) and thus
not a cfs problem at all, although malloc() and its ilk seem to be quite
solid in other respects on the Sun.
In an attempt to minimize the problem without taking the time to try
to understand it, I started killing and restarting the cfsd process every
night from cron. I've noticed no problems since I began doing this and
it has made cfsd nearly bullet-proof. It does forcibly free up resources
and also forcibly "cdetaches" any directories that were attached at the
time. (You can easily insert a check to only respawn the daemon if there
are no attached directories, if this latter point is a problem.) Note
that although the daemon is initially started prior to the mount, there
appears to be no need to remount after restarting the daemon.
It worked for me, you might find it helpful...
--
Rob Stampfli rob@colnet.cmhnet.org The Bill of Rights: It was a
614-864-9377 HAM RADIO: kd8wk@w8cqk.oh good thing while it lasted...
