Xref: utzoo comp.databases:1810 comp.unix.xenix:4432
Path: utzoo!attcan!uunet!lll-winken!ames!pasteur!ucbvax!decwrl!labrea!rutgers!bpa!cbmvax!vu-vlsi!devon!chessene!root
From: root@chessene.UUCP (This System)
Newsgroups: comp.databases,comp.unix.xenix
Subject: Re: free form texual database
Summary: rtfm
Message-ID: <223@chessene.UUCP>
Date: 10 Jan 89 18:50:36 GMT
References: <397@ispi.UUCP> <379@fsc2086.FSC.COM> <451@marob.MASA.COM>
Organization: Competitive Computer Systems, Lancaster PA
Lines: 31

In article <451@marob.MASA.COM>, daveh@marob.MASA.COM (Dave Hammond) writes:
% In article <379@fsc2086.FSC.COM> jim@fsc2086.FSC.COM (Jim O'Connor) writes:
% >In article <397@ispi.UUCP>, jbayer@ispi.UUCP (Jonathan Bayer) writes:
% >> has to be able to store entries of arbitrary length (anywhere from a few
% >> lines to several pages), and be indexed by at least a header, [...]
% >Why not use the Xenix directory structure itself?  You could write a few
% >programs to accept the data (sounds like a WP file), create the header[...]
% >...

% I went this route on a project a few years ago, and was sorry later that
% I did.  The advantage of data manipulation with standard tools was far
% overshadowed by the tremendously inefficient disk usage.  Because of the
% filesystem inode limit, we were bound to a maximum of ~16,000 inodes on
% a 30mb partition.  With the average database entry size under 1K, the
% partition was effectively "filled" at ~16Mb, or half capacity.

RTFM. I had the same problem with the spool filesystem running out of inodes
when I started getting news.

NAME
	mkfs - construct a file system
SYNOPSIS
	/etc/mkfs special sectors[:inodes] [gap sectors/cyl]
				  ^^^^^^^

Or were you running a version of UN*X even more brain-damaged than ours is?
(That can't be possible... :-)
--
Mark Buda                                Domain: hermit@chessene.uucp
Dumb: ...rutgers!bpa!vu-vlsi!devon!chessene!hermit
"Here, with a compressed air drill, parsnips are harvested." - an old newsreel