Re: DEVFSv50 and /dev/fb? (or /dev/fb/? ???)

[Terry L Ridder]

Theodore Y. Ts'o wrote:
> 
>    Date:        Wed, 05 Aug 1998 02:26:21 -0500
>    From: Terry L Ridder <[e-mail]>
> 
>    Concerning the >2GB files on Intel hardware I agree that is a hard
>    one.  Which is why I have been bringing it up. Are we as a Community
>    going to consider the requirements that Oracle & Informix support
>    bring to the table?
> 
> I keep hearing this one, but quite frankly, I'm not convinced.  Oracle
> strongly recommends that you use raw disk partitions for its databases,
> not regular Unix files.

I agree, both Oracle & Informix recommend that the database be on a raw
disk partition for optimal performance. That being said there are
however
several instances where a "quick and dirty" "cooked" file database are
required/wanted/desired/needed/etc. It is in those cases where >2GB
files
are needed.

> 
> The issue of raw disk access is more important, but even there I'd be
> surprised if Oracle could get the functionality they needed using
> fsync().

Again I agree, raw disk access is more important, but only when
discussing
"stationary" databases. Being able to have a database on a
laptop/notebook
which by nature of the application the database is "transient" "cooked"
files are an alternative.

> 
> Personally, my feeling is that B-tree support to make large directories
> searches is more important than >2GB files.  More people will win as a
> result of doin the B-tree work than will win doing the >2GB files work.
> So that's how I'm setting my priorities.  Other folks are of course free
> to set their own priorities.

I have no feel for which is more common; directories with a large number
of small files or directories with a small number of large files. Does
anyone have a feel on this?

My input comes from a small number of large files.

> 
> If someone who understands the kernel programming issues wants to try to
> tackle the >2GB file problem, I'd be happy to work with them.  There's a
> cheat you can do which bypasses the generic file read/write routines
> (which require >2GB support in the VFS) for files >2GB which would
> probably not be *that* hard to do.  It might not be the most efficient
> thing in the world, since it would have to bypass the page cache, but it
> would at least provide the basic level of functionality.
> 
>                                                 - Ted

-- 
Terry L. Ridder
Blue Danube Software (Blaue Donau Software)
"We do not write software, we compose it."

 When the toast is burnt
 and all the milk has turned
 and Captain Crunch is waving farewell
 when the Big One finds you
 may this song remind you that they 
 don't serve breakfast in hell
 ==Breakfast==Newsboys