[121] in The Cryptographic File System users list
Re: Memory usage on large encrypted volumes
daemon@ATHENA.MIT.EDU (Matt Blaze)
Mon Jan 25 19:43:27 1999
From owner-cfs-users@research.att.com Tue Jan 26 00:43:26 1999
Return-Path: <owner-cfs-users@research.att.com>
Delivered-To: cfs-mtg@bloom-picayune.mit.edu
Received: (qmail 24176 invoked from network); 26 Jan 1999 00:43:25 -0000
Received: from unknown (HELO mail-blue.research.att.com) (135.207.30.102)
by bloom-picayune.mit.edu with SMTP; 26 Jan 1999 00:43:25 -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 EF07E4CEB9; Mon, 25 Jan 1999 19:43:25 -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 TAA16250;
Mon, 25 Jan 1999 19:43:23 -0500 (EST)
Received: (from majordomo@localhost) by nsa.research.att.com (8.7.3/8.7.3) id TAA00656 for cfs-users-list; Mon, 25 Jan 1999 19:42:04 -0500 (EST)
X-Authentication-Warning: nsa.research.att.com: majordomo set sender to owner-cfs-users@nsa.research.att.com using -f
Received: from amontillado.research.att.com (amontillado.research.att.com [135.207.24.32]) by nsa.research.att.com (8.7.3/8.7.3) with ESMTP id TAA00649 for <cfs-users@nsa.research.att.com>; Mon, 25 Jan 1999 19:42:02 -0500 (EST)
Received: from nsa.research.att.com (root@nsa.research.att.com [135.207.24.155])
by amontillado.research.att.com (8.8.7/8.8.7) with ESMTP id TAA16220;
Mon, 25 Jan 1999 19:43:12 -0500 (EST)
Received: from nsa.research.att.com (mab@localhost.research.att.com [127.0.0.1]) by nsa.research.att.com (8.7.3/8.7.3) with ESMTP id TAA00642; Mon, 25 Jan 1999 19:42:00 -0500 (EST)
Message-Id: <199901260042.TAA00642@nsa.research.att.com>
To: Brett Eldridge <beldridg@best.com>
Cc: cfs-users@research.att.com
Subject: Re: Memory usage on large encrypted volumes
In-reply-to: Your message of "Mon, 25 Jan 1999 12:02:13 PST."
<Pine.LNX.4.03.9901251157550.4988-100000@fuel.home.net>
Date: Mon, 25 Jan 1999 19:42:00 -0500
From: Matt Blaze <mab@research.att.com>
Sender: owner-cfs-users@research.att.com
Precedence: bulk
>On Mon, 25 Jan 1999, Matt Blaze wrote:
>
>> 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
>
>Okay, now I understand.
>
>> as a directory is attached (since you might reference a handle
>> that was given out long ago).
>
>So, if I cdetach the directory will cfsd release the memory?
Yes. However, CFS uses malloc to get the memory, so whether it returns
released memory back to the OS is an implementation issue. (Some
implementations of malloc do, others (particularly older ones) don't.
>
>> I've been re-working this for cfs 2.0, which will also incorporate
>> a number of other nice things. Unfortunately, I've been very
>> slow about getting this done.
>
>No worries. What else is on the burner for 2.0?
>
I'm also re-working the crypto mode to be based on file system blocks
rather than cipherblocks. I now believe that the workloads and performance
characteristics on which I based the CFS design are out of date (processors
are faster, most applications use the stdio library, etc.) and are
a rather poor fit for modern applications. In the next implementation,
I'm using standard CBC mode on a FS block basis, with a hash of a file
ID and the block number used as the IV. This will be at least as secure
as the current mode, be very slightly more expensive for certain workloads
(especially certain databases), but has the virtue of using less memory
and making it easier to integrate ciphers with other-than-8-bit blocks
(like AES candidates).
Unfortunately, I can't promise a delivery date...
-matt
