Hi,
I found out, that the option O_DIRECT for opening a file on a fat-
filesystem successfully completes. But reading and writing to that
file leads to EINVAL errors (using kernel 2.6.18).
I would like to access on certain files on a flash-disk without cache
usage, whereas the rest of the filesystem shall be accessed normally/cached.
I am aware of the previous discussion. My application is not targetting on a
pure file usage (I can live with the existing features for that), but also
for a side-channel IO to interact with the device.
Do you see a way to solve my problem by any workaround? Is O_DIRECT
support for fat-fs feasible in future?
Grateful for any response.
Thanks in advance
Hubi
> I would like to access on certain files on a flash-disk without cache
> usage, whereas the rest of the filesystem shall be accessed normally/cached.
> I am aware of the previous discussion. My application is not targetting on a
> pure file usage (I can live with the existing features for that), but also
> for a side-channel IO to interact with the device.
Assuming you basically want to be sure writes hit the media you can use
the fsync and fdatasync system calls on modern kernels to ensure your
data is on the media and is flushed when you want it not when the kernel
gets around to it out of boredom.
Hubertus Grobbel <[email protected]> writes:
> I found out, that the option O_DIRECT for opening a file on a fat-
> filesystem successfully completes. But reading and writing to that
> file leads to EINVAL errors (using kernel 2.6.18).
EINVAL may be meaning the memory alignment which you passed to syscall
is wrong.
> Do you see a way to solve my problem by any workaround? Is O_DIRECT
> support for fat-fs feasible in future?
The fatfs is supporting O_DIRECT for read, for write it's partially
supporting (can't extend file size).
--
OGAWA Hirofumi <[email protected]>
On Tue, May 15, 2007 at 01:02:51AM +0100, Hubertus Grobbel wrote:
> I found out, that the option O_DIRECT for opening a file on a fat-
> filesystem successfully completes. But reading and writing to that
> file leads to EINVAL errors (using kernel 2.6.18).
Make sure your buffer is page aligned and read/write in multiples of
the hard block size (use blockdev --getss to figure out).
Erik
--
They're all fools. Don't worry. Darwin may be slow, but he'll
eventually get them. -- Matthew Lammers in alt.sysadmin.recovery
Hi Alan, Erik and Hirofumi and the rest,
I want to inform you of my success. So first of all thanks for your help!
Assuring, that the buffer is aligned according 4k (pagesize = getpagesize()
and multiple of sectorsize = blockdev --getss) using memalign or
posix_memalign, did the job. Thanks a lot. A very nice feature.
The compiler option -D_GNU_SOURCE helped also to avoid including asm-header of
fcntl.h.
bye
Hubi