Messages in this thread | | | Date | Mon, 21 Dec 1998 22:33:06 +0100 (MET) | From | Gerard Roudier <> | Subject | Re: 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/
| |