From owner-freebsd-hackers Tue Jul 30 17:10:41 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA19528 for hackers-outgoing; Tue, 30 Jul 1996 17:10:41 -0700 (PDT) Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id RAA19520 for ; Tue, 30 Jul 1996 17:10:39 -0700 (PDT) Received: from rah.star-gate.com (localhost.v-site.net [127.0.0.1]) by rah.star-gate.com (8.7.5/8.7.3) with ESMTP id RAA00471; Tue, 30 Jul 1996 17:08:47 -0700 (PDT) Message-Id: <199607310008.RAA00471@rah.star-gate.com> X-Mailer: exmh version 1.6.5 12/11/95 To: Terry Lambert cc: davidg@Root.COM, heo@cslsun10.sogang.ac.kr, freebsd-hackers@FreeBSD.org Subject: Re: your mail In-reply-to: Your message of "Tue, 30 Jul 1996 13:11:44 PDT." <199607302011.NAA00436@phaeton.artisoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 30 Jul 1996 17:08:45 -0700 From: Amancio Hasty Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Unless he has a creative way of handling lots of mpeg files , then I doubt that he needs such a mechanism for transversing directories. I believe what the original poster was after is to eliminate caching mpeg files in memory which doesn't bother me that much. I supposed that for mpeg2 , to conserve memory or a video server this is important;however, for mpeg1 requiring a 150KB stream is hardly worth doing. The first thing I would try to do is to spec out the system: 1. cost 2. cpu 3. memory 4. disks / controllers 5. mpeg decoder 6. server or standalone unit >From The Desk Of Terry Lambert : > > From The Desk Of David Greenman : > > > > 4) How can user process access the file in ufs filesystem through raw d isk? > > > > > > You can't unless you write a user-mode UFS/FFS that does it's I/O thro ugh > > > the raw device. I couldn't imagine why you'd want to do this, however. > > > > > > > My guess is that his assumption is that accessing the files via a > > "raw disk mode" will be faster than going thru the normal file > > access mechanism. I wish I knew what is he up to so we can help him or > > better yet his justification for taking such approach . > > You can more efficiently traverse a directory this way; specifically, > you avoid the system call boundry push problem when you have blocks > of crap file names that don't match the pattern you are looking for. > > > Terry Lambert > terry@lambert.org > --- > Any opinions in this posting are my own and not those of my present > or previous employers.