5

Does "ecryptfs" support direct I/O? In general, how can a "stackable" file system, that modifies buffer provided by user support direct I/O?

ghostkadost
  • 502
  • 4
  • 14
  • 1
    Direct I/O means nothing else but "data does not come from and does not go into the buffer cache". Insofar, there is no reason why any particular filesystem should not be able to support it. Of course in the case of an encrypted filesystem, it will mean that each time you read a sector, it must be decrypted over and over again... – Damon Aug 29 '11 at 18:32
  • The concern here is how is a write operation implemented. If there can be no copy, then we must encrypt the data in user buffer, perform write operation and then decrypt the data again as we cannot leave user buffer modified. This should be difficult when asynchronous I/O is also thrown into the picture. – ghostkadost Aug 30 '11 at 14:25
  • 1
    `O_DIRECT` does not offer asynchronous operation or promise an awful lot otherwise. All it _really_ promises is to (original quote) "try to minimize cache effects" by not going via the buffer cache. It does _not_ give a guarantee that no copies are made, ever. It does avoid copies that it can avoid. And, more often than not, it does the opposite of what people think (degrade performance). Obviously if you encrypt a sector, unless the disk controller has HW encryption you must make a copy of it, but you can't help that. It will _still_ not go into the buffer cache afterwards, though. – Damon Aug 30 '11 at 15:33

2 Answers2

3

ecryptfs does not support direct I/O.

There is no implementation of direct_IO() callback in ecryptfs address_space_operations.

Nikolai
  • 1,325
  • 12
  • 24
  • Still it would be nice to know how can this be added to stackable file systems that modify the data. Especially when asynchronous IO is performed with Direct I/O. How can we guarantee the consistency of user buffer *and* maintain the semantics of direct I/O? – ghostkadost May 22 '13 at 10:14
0

I haven't looked into this much, but I would personally use a decorator pattern for the file system drivers, so that ecryptfs sits on top of any of the actual device drivers. Then when calls are made, they go into ecryptfs code, then ecryptfs calls the device drivers and does the writing.

VolatileDream
  • 1,083
  • 7
  • 15