Return-Path: <owner-os2-unix@eyup.org>
Received: from mail.eyup.org (212.69.253.65) by mail.epost.de (5.5.056)
        id 3C97AA8600042B00; Thu, 21 Mar 2002 00:44:28 +0100
Received: by mail.eyup.org (IBM OS/2 SENDMAIL VERSION 2.03/2.0) id XAA175.40; Wed, 20 Mar 2002 23:25:38 GMT
Received: from hueymiccailhuitl.mtu.ru by mail.eyup.org (IBM OS/2 SENDMAIL VERSION 2.03/2.0) id XAA175.36; Wed, 20 Mar 2002 23:25:34 GMT
Received: from p0.f81.n5020.z2.fidonet.org (ppp100-230.dialup.mtu-net.ru [212.188.100.230])
	by hueymiccailhuitl.mtu.ru (Postfix) with SMTP id 2675CF846C
	for <os2-unix@eyup.org>; Thu, 21 Mar 2002 02:25:26 +0300 (MSK)
	(envelope-from andrew_belov@newmail.ru)
From: "Andrew Belov" <andrew_belov@newmail.ru>
To: "os2-unix@eyup.org" <os2-unix@eyup.org>
Date: Thu, 21 Mar 2002 02:23:14 +0300 (MSK)
X-Mailer: PMMail 2.10.2010 for OS/2 Warp 4.50
MIME-Version: 1.0
Content-Type: text/plain; charset="koi8-r"
Content-Transfer-Encoding: 7bit
Subject: [UnixOS2] RAMFS performance patch
Message-Id: <20020320232526.2675CF846C@hueymiccailhuitl.mtu.ru>
Sender: owner-os2-unix@eyup.org
Precedence: bulk
Reply-To: os2-unix@eyup.org


I have created a Q&D patch that eliminates the performance degradation of RAMFS on 
large files, so the processing time is no longer proportional to size_of_file^2, and 
RAMFS handles creation of CD-images and archiving quite normally.

If somebody wants to test it, then download ftp://ftp.unixos2.org/incoming/ramfs64p.zip 
and install it over the RAMFS files (there is a pre-built debug version too). The 
RAMFS64 fix (to report 64M of free space rather than 1M) is there as well.

For the heavy-duty operation it should be noted that this solution is still far from perfect - 
if there is a plenty of relatively small files, two side-effects will be likely observed:

(1) memory overhead - 4K per each file for cluster map, i.e. 15000 files now require 60 
extra megabytes.

(2) the kernel VMM will starve as RAMFS allocates too many separate objects: a 64K 
file will consume 7 chunks of different size rather than a single 64K piece as before. The 
"critical mass" for my 14.xxx system is about 15000 files totalling 270M, while the 
genuine RAMFS allowed for 57000 files.

On the other hand, RAMFS becomes pretty well suitable for temporary activities. In long 
term, it may even be enhanced with a "hard link" feature as it already contains the 
"inodes" represented by cluster maps, missing only an API.