Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752812AbdHBPFf (ORCPT ); Wed, 2 Aug 2017 11:05:35 -0400 Received: from mail-qk0-f169.google.com ([209.85.220.169]:37142 "EHLO mail-qk0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751894AbdHBPFd (ORCPT ); Wed, 2 Aug 2017 11:05:33 -0400 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@TELEMANN.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" X-Mailer: Evolution 3.24.4 (3.24.4-1.fc26) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 918 Lines: 23 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