Date: Tue, 30 Jul 1996 17:08:45 -0700 From: Amancio Hasty <hasty@rah.star-gate.com> To: Terry Lambert <terry@lambert.org> Cc: davidg@Root.COM, heo@cslsun10.sogang.ac.kr, freebsd-hackers@FreeBSD.org Subject: Re: your mail Message-ID: <199607310008.RAA00471@rah.star-gate.com> In-Reply-To: Your message of "Tue, 30 Jul 1996 13:11:44 PDT." <199607302011.NAA00436@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199607310008.RAA00471>