Re: [PATCH] support O_DIRECT in tmpfs/ramfs

[Michael Reed <mdr@sgi.com>]

Peter Staubach wrote:
> Hua Zhong wrote:
>> Hi,
>>
>> A while ago there was a discussion about supporting direct-io on tmpfs.
>>
>> Here is a simple patch that does it.
>>
>> 1. A new fs flag FS_RAM_BASED is added and the O_DIRECT flag is ignored
>>    if this flag is set (suggestions on a better name?)
>>
>> 2. Specify FS_RAM_BASED for tmpfs and ramfs.
>>
>> 3. When EINVAL is returned only a fput is done. I changed it to go
>>    through cleanup_all. But there is still a cleanup problem:
>>
>>   If a new file is created and then EINVAL is returned due to O_DIRECT,
>>   the file is still left on the disk. I am not exactly sure how to fix
>>   it other than adding another fs flag so we could check O_DIRECT
>>   support at a much earlier stage. Comments on how to fix it?
> 
> This would seem to create two different sets of O_DIRECT semantics,
> wouldn't it?  I think that it would be possible to develop an application
> using one of these FS_RAM_BASED file systems as the testbed, but then be
> surprised when the application failed to work on other file systems such
> as ext3.

As I'm ignorant with regard to what is needed for "compliant"
support of O_DIRECT on tmpfs, what are the issues with actually implementing
the proper semantics, including the alignment and any transfer length
restrictions?

My $.02 is that the implementation should be fully compliant with the
current semantics or it shouldn't be implemented.  And I think it should
be implemented.

Mike

> 
>       ps
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 
>