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 [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
