lkml.org 
[lkml]   [1998]   [Dec]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: PATCH: Raw device IO for 2.1.131
In <19981221180256.B27974@arthur.zdv.Uni-Mainz.DE> Dominik Kubla (dominik.kubla@uni-mainz.de) wrote:
DK> On Wed, Dec 16, 1998 at 11:01:54AM +0300, Khimenko Victor wrote:
>> > OK, a possible "technical" problem is, I want to have 2 linux boxes(or more)
>> > connected to the same scsi disks. (twin tailed or what have you). I have
>> > running 2 instances of the same software both accessing those disks. For
>> > obvious reasons, load balancing, spread load of jobs, and failover, if a
>> > node fails, at least the other instance still has access to the disk and can
>> > RECOVER the data. Because my logfiles are also 'shared' so I can access the
>> > other node's logfiles and recover from that.
>>
>> I'm could not see how this all will work without specially designed software
>> and hardware !

DK> So what? That just tells you that you don't know everything: A lot of people
DK> could show you how it is done reliably with of the shelf hardware and software.

"Specially designed hardware" != "not shelf hardware" :-) BTW hardware part is
more flexible here then software part ...

>> Since this problem is not raised in this thread yet :-)) IMO the only clear
>> solution would be changes in ext2fs or may be special filesystem.
DK> [...]
>> > There is also the fact that raw io for databases IS faster. Whatever type
>> > filesystem you design, doesn't matter since we know which blocks to write
>> > where. An index entry points to a specific block/file/slot so its easy to
>> > calculate the offset in the 'file' ;) And except for full table scans, the
>> > data is spread allover the place, so read-ahead into buffercache doesn't do
>> > didley squad in that case.
>>
>> But you still should keep track of space used for different tables in
>> database :-)) This is EXACTLY filesystem work. Of course you could make
>> internal filesystem in database but of course much more clear way is to
>> fix/extend existing filesystem.

DK> No it is not, ever heard of OS/400?

Of course. There are database as core of the system. *nix is not designed this
way. Both designs has benefits but analogy: both swiss roll and stockfish
are nice food while swiss roll with stockfish is ...

DK> And in addition a filesystem can not do all the things databases would like
DK> it to do unless the filesystem was specially tailored for the specific
DK> database APPLICATION.

DK> RAW DEVICES are simply a short cut of the system to allow databases to use
DK> "filesystems" specially tailored for the specific application (the on site
DK> application, not the database as distributed by the vendor). Not more and not
DK> less. So why don't they use the VFS API provided by most (but not all!)
DK> systems? Simple: because this makes the database system-dependant and
DK> unnecessary complex. And complexity kills software.

Exactly. And raw devices support makes kernel unnecessary complex and (even more
important!) much more flexible. "And complexity kills software" :-)) And since
this is not needed by 99% (more like 99.99% :-) of users mainstream kernel will
not include raw devices support :-))

DK> Above you were stating that special filesystems would be the solutions
DK> to the problem. They are and the only system independant way to do this are
DK> raw devices.

Create module for raw access. Create special filesystem (better way IMO). Do not
pollute mainstream kernel with stuff needed by only 1% (more like 0.01%) of
users just as "temporary solution". Linux is not Solaris or HP-UX: it could be
tweacked as needed and when needed.




-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:46    [W:0.309 / U:1.740 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site