Nick Piggin <nickpiggin@xxxxxxxxxxxx> wrote: > Hmm, I guess not all filesystems define write_begin/write_end. But if you > only need to use ones that do define them? That would be a reasonable restriction. As would excluding NFS, AFS, CIFS, etc.. > Yes, you framed the changelog as introducing this new callback because it > allows a highly optimised code that takes advantage of page aligned write. > So I went on a tangent thinking you were going to use it later to avoid > the data copy or something. I would love to avoid the data copies and do asynchronous direct I/O. However the DIO interface appears very highly userspace centric, and is very hard to use from within the kernel. > You are knowingly squashing together fscache and the backing filesystem if > you do something like introduce a flag like PG_owner_priv_2 and disallow the > backing filesystem from reusing it. The backing filesystem isn't disallowed from reusing it; the *netfs* is. Understand that there are two filesystems involved: The netfs, which makes requests of FS-Cache, and the backing filesystem which cachefiles uses to store data. FS-Cache places restrictions such as having to yield up FS_private_2 and FS_owner_priv_2 on the netfs. Cachefiles places restrictions such as must have bmap(), setxattr(), write_one_page() on the backing fs. > So at which point you don't have to keep up illusions about being totally > filesystem agnostic. I'm trying to keep things as filesystem agnostic as I can, at both ends. > Many filesystems don't need the file argument to write_begin/write_end. That probably includes all those I care about for supporting the backing fs. The problem is how does cachefiles tell? Perhaps a file_system_type flag? #define FS_SUPPORTS_CACHEFILES 65536 or #define FS_NULL_FILEPTR_OKAY 65536 perhaps. David -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
