lkml.org 
[lkml]   [2017]   [Aug]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Subjectcoda's use of file->f_mapping and inode->i_mapping
From
Date
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@redhat.com>

\
 
 \ /
  Last update: 2017-08-02 17:06    [W:0.342 / U:0.100 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site