okay I give you an example, currently ecryptfs does not support DIRECT IO operation, if it wants to encrypt data in kernel buffers and since file was opened in DIRECT IO mode, the lower filesystem should not complain about kernel buffers
Thanks,
Rajat
On Tue, Oct 19, 2010 at 12:56 AM, Greg Freemyer <greg.freemyer@xxxxxxxxx> wrote:
Rajat,On Mon, Oct 18, 2010 at 3:19 AM, Rajat Sharma <fs.rajat@xxxxxxxxx> wrote:
>
>> Doesn't that mean user space right to block device? Simply based on
>> that, I can see you fail all these times... because you do it from
>> kernel space..and that's against the very basic meaning of direct I/O
>
> You can visualize direct I/O for two purpose:
>
> 1. Zero copy directly from user buffers to block device as you pointed out.
> 2. Don't make an extra effort to cache the data in page-cache, as it might
> have already be done by applications.
>
> In some cases, you may not afford to solve 1., e.g. you may want to
> manipulate data before writing it do target. Although this can be done on
> the same user space buffer, but you may not want to do that because it may
> change the working data set of application.
>
> Anyways, to cut it short again, I had put my requirements in my original
> mail, and I have one solution where I map pages in user space, I am looking
> for a better solution, or the verification that there is none, where I can
> directly user kernel buffers for doing non-cached I/O.
>
> Rajat
I'm not specifically familiar with a use-case in the kernel where the
data based in via directio call is copied to kernel buffers,
manipulated, then passed on. Thus I seriously doubt your use-case is
supported.
Why do you want to do that in the first place?
Greg
