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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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>



[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux