coda's use of file->f_mapping and inode->i_mapping

[Jeff Layton]

I've been slowly crawling through filesystems to convert them to
errseq_t based error handling for ->fsync operations. I started looking
at coda, but it does some strange things with the f_mapping that I don't
quite understand.

When a file is opened on coda, we call down to userland daemon, which
opens the file and passes the fd back to the kernel. The kernel then
converts that to a struct file pointer and stores that in the
coda_file_info->cfi_container. So far, so good...

The weird bit is that in coda_file_mmap, we then do this:

        coda_file->f_mapping = host_file->f_mapping;
        if (coda_inode->i_mapping == &coda_inode->i_data)
                coda_inode->i_mapping = host_inode->i_mapping;


What is the significance of mmap on coda files? If you want to monkey
around with the i_mapping and f_mapping, wouldn't it make more sense to
do so at open() time?

-- 
Jeff Layton <jlayton@xxxxxxxxxx>