Direct IO read and write

Sorry, but eCryptfs does not currently have direct I/O support.

I'd definitely be willing to merge it if someone contributed the code, but I have no short-term plans to add the support.

Many thanks for a very quick answer.

Is there maybe another way to bypass buffer cache somehow? We have a file on the SD card where data are written first through the FS, then the CPU of the SD card makes same changes within the file and this changes content has to be read out. For the FS this change is not visible, thus by reading it returns the data from the cache which is not good for us :-(

Thus the real solution is direct read/write or if that is not supported then some other trick to bypass or empty the buffer cache (e.g. bu doing something between write and read, e.g. overflooding through another big file or something similar). Any idea how this could be realized when eCryptfs is the underlying FS layer?

It is related to the questions such like:
- buffer cache size
- caching mechanism

This is how the SD card is mounted:
/mnt/sdcard-ext /mnt/sdcard-ext ecryptfs rw,dirsync,nosuid,nodev,noexec,relatime
,ecryptfs_sig=5793233431cfd5d3,ecryptfs_cipher=aes,ecryptfs_key_bytes=32,ecryptf
s_passthrough,no_new_encrypted 0 0

Appreciate any help orideas how to overcome this.

This sounds like a one-off implementation (or a product?) and I don't really have enough information to help.

From what I can make out about what you're doing, it sounds like you're going to have eCryptfs and whatever else is modifying the encrypted file on the SD card overwiting each other's data. If you're not using some form of syncronization between eCryptfs writing out data and the SD card processor modifying the files, direct IO won't even help you.

Keep in mind that eCryptfs can write out an "extent" worth (4096 bytes) of data each time a single plaintext byte is modified. In other words, if you're changing a byte at offset 0 (inside the eCryptfs mount) and the SD card processor is changing the same file at offset 4095, one of those updates may get lost.

Trying to force a page cache flush is a little unpredictable and is really just a bandaid to your problem. I wouldn't suggest it.

At the end the point is just to ensure that I really read out from the card and not from the cache (that's what direct IO does). So what I have to do:
1) Write data to a file on the SD card ensuring that the data are really written to the SD card and not stored somewhere in the cache -> so far ok
2) Afterwards the SD controller will (based on the data written from the outside) do some calculation and write some new data back and on the same position of the file
3) Then I have to read out this new data from the file and this is where the problem happens
As no direct IO is supported and as initially written data are in cache, FS is not newly reading out the data from the SD card but return those which in the cache -> so there is no chance for me to get the data which has been changed by the SD controller

So one solution would be to force direct read (direct IO), but as discussed this is not currently supported by eCryptfs. Another solution (which is realizable on some mobile platforms) would be to bypass flash, but for this I would have to know how the cache mechanism is realized in eCryptfs in order to force the cache buffer to be emptied between steps 1 and 3, so tha then I'm performing the step 3 FS has to read out from the SD card again.

Is eCryptfs providing such a functionality to clean up the cache programmatically? Os is there another programmatical way to force such a clean up of the cache? How? Any example source code?

No, eCryptfs doesn't provide a way to force everything out of the page cache. There is /proc/sys/vm/drop_caches but depending on that would be one serious/dangerous hack for you to rely on.

Direct IO support may solve the problem, but it still seems like there needs to be some syncronization between eCryptfs writing out data and the SD controller modifying what is being written out.

Sorry, but I really can't help with the specifics of this anymore. It is just too specific to your use case. If you'd like to contribute direct IO patches, I'd be happy to review and merge them when appropriate. If you want me to help you figure out how to make eCryptfs work with what sounds like a one-off peripheral that you're creating, I can't do that.

Good luck!