lkml.org 
[lkml]   [1998]   [Dec]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Should raw I/O be added to the kernel?


On Sun, 20 Dec 1998, Ronald Cole wrote:

> Linus Torvalds <torvalds@transmeta.com> writes:
> >The only argument for raw disk IO is the caching policy issue
>
> Exactly right. Without raw disk IO, you couldn't guarantee a database
> to always be in a consistent state on the disk (i.e. it isn't very
> desirable to have a committed transaction in a cache when the pc loses
> power). It makes it impossible to recover the database. And what
> good is having a transaction oriented database on Linux in a
> production environment if you can't be guaranteed to recover it after
> a crash?

If you want performances, then you also want to queue several IOs to the
device at a time, each time it is possible. Imagine now, that you got an
IO error on some IO currently being processed by the device. In SCSI you
will get an ACA condition if the device supports it. If you want to really
stay consistant, then you want to try to recover from this error.
Generally, the application does not know at which level (driver level,
controller level, device level, ...) each pending IOs is currently queued.
Having a consistant view of the ordering of IOs from the application is
generally not possible with existing systems in case of IO error.

On the other hand, hard drives may have the QUEUE ALGORITM QUALIFIER set
to 1. That means that the application client does not require the device
to take care of ordering for pending SIMPLE TAGGED IOs that overlap. Data
base manager probably only queue IOs that donnot conflicts as do most
kernels. And hard disks may have write caching enabled, without the
application (data base manager) knowing of that ...

BTW, I could also mention RAID arrays and especially software-RAID, but
this would be too long ...

Could you tell us how existing database managers guarantee consistency
in case of IO error ?

> >From my days at Unify a decade ago, you had to use raw disk IO because
> fsync() wasn't guaranteed to have flushed the cache completely to the
> disk before it returned. Of course, I'll be the first to admit that I
> haven't checked out the kernel source to see if this is true for
> Linux. But, I'm sure that someone will so that the database part of
> this thread can be put to rest.

The fact that the THING you are raw-ioing :) returns good status does not
guarantee that the data has been successfully written to the media when
some kind of write caching is performed by the raw-ioed THING. You may get
deferred errors in such a situation if some error occurs and you have
several IOs queued to the THING at this time.

You wrote:

> Exactly right. Without raw disk IO, you couldn't guarantee a database
> to always be in a consistent state on the disk (i.e. it isn't very

I reply you that even with raw disk IO, it is not that easy to _really_
guarantee such a consistency without being _really_ aware of what may
_really_ happen with _real_ IOs, and that _real_ IO system services
are generally too poor to allow full control on what _really_ happens
with IOs.

I would be glad if Linux provided DIRECT IO from user space. This would
be helpfull, IMO, for some applications that would gain advantage of
it. But the concept of RAW disk IO is extremally _poor_ in my opinion and
at the moment are only usefull to implement file systems from user-land
as it seems database manager do.

One of the reason of Linux not having raw IOs is that Linux does not use
the KVA as a virtual mapping for supplying virtually contiguous buffers to
drivers, but constructs scatterlists directly from kernel buffers and
supplies scatterlists to drivers. And under Linux, only the initial kernel
memory mapping is IOable (e.g. allow use of virt_to_bus() address
translation to provide memory bus addresses to IO controllers for DMA).
This design choice made raw IO implementation not simple to implement
under Linux, despite the fact that it seemed way trivial to implement on
some other O/Ses.

Regards,
Gerard.


-
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.113 / U:0.948 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site