From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: <1501686331.4654.6.camel@redhat.com> Subject: coda's use of file->f_mapping and inode->i_mapping From: Jeff Layton To: Jan Harkes , coda@cs.cmu.edu Cc: codalist@coda.cs.cmu.edu, linux-fsdevel , open list , David Howells , Al Viro Date: Wed, 02 Aug 2017 11:05:31 -0400 Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: 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