Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 21 Aug 2001 18:03:08 -0700
From:      Darryl Okahata <darrylo@soco.agilent.com>
To:        Oscar Bonilla <obonilla@galileo.edu>
Cc:        freebsd-hackers@FreeBSD.ORG
Subject:   Re: secure Filesystem 
Message-ID:  <200108220103.SAA05763@mina.soco.agilent.com>
In-Reply-To: Your message of "Tue, 21 Aug 2001 18:34:32 MDT." <20010821183432.A5883@galileo.edu> 

next in thread | previous in thread | raw e-mail | index | archive | help
Oscar Bonilla <obonilla@galileo.edu> wrote:

> >      A bigger problem is that doing anything with a file uses up 1-2KB
> > PER FILE.  If you want to see cfsd grow *really big*, do a "find ." of
> > any large cfs-controlled hierarchy with lots of files.  I'd really like
> > to put my MH mail messages under cfs, but I've got too many files (I
> > can't afford having a 200+MB cfsd).
> 
> I don't seem to have that problem...
> 
> voyager ~ > du -sk crypt
> 1342056 crypt
> voyager ~ > find /crypt/obonilla >& /dev/null 
> voyager ~ > du -sk crypt
> 1342056 crypt

     No.  You need lots of files, not lots of disk space used.

[ You might have lots of files, but I can't tell from the above.  ]

     Assuming that you have lots of files (> 10000, if possible) below
/crypt/obonilla, you need to look at the size of the cfsd daemon.  The
disk space taken will not change -- it's the memory consumption of the
cfsd daemon.  If you have only a few files (oh, say, < 1000), you're
probably fine.  If you have lots of RAM (oh, 256MB or more), you may not
notice any problems.

[ For an easy way of seeing cfsd grow, run top(1) *WHILE* the find(1) is
  running.  Look at the "Size" and "Res" fields.  ]

     Also, if you have lots of files, the find(1) of the cfs-controlled
hierarchy should run significantly slower than if find(1) was running on
a plain hierarchy.  The reason is that cfsd uses a 1024-entry hash table
at the top level; everything's a linked list below that (I think).  Due
to the size of this table, cfsd will thrash the disk if the system goes
into swap.

     I may play with bumping the table size up to 128K or so (I'm not
sure if the hash function can handle it, though).  Increasing the table
size might help lessen the thrashing.

-- 
	Darryl Okahata
	darrylo@soco.agilent.com

DISCLAIMER: this message is the author's personal opinion and does not
constitute the support, opinion, or policy of Agilent Technologies, or
of the little green men that have been following him all day.

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200108220103.SAA05763>