From: Jeff Layton <jlayton@redhat.com>
To: Jan Harkes <jaharkes@cs.cmu.edu>, coda@cs.cmu.edu
Cc: codalist@coda.cs.cmu.edu,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
open list <linux-kernel@vger.kernel.org>,
David Howells <dhowells@redhat.com>,
Al Viro <viro@zeniv.linux.org.uk>
Subject: coda's use of file->f_mapping and inode->i_mapping
Date: Wed, 02 Aug 2017 11:05:31 -0400 [thread overview]
Message-ID: <1501686331.4654.6.camel@redhat.com> (raw)
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>
WARNING: multiple messages have this Message-ID (diff)
From: Jeff Layton <jlayton@redhat.com>
To: Jan Harkes <jaharkes@cs.cmu.edu>, coda@cs.cmu.edu
Cc: codalist@TELEMANN.coda.cs.cmu.edu,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
open list <linux-kernel@vger.kernel.org>,
David Howells <dhowells@redhat.com>,
Al Viro <viro@zeniv.linux.org.uk>
Subject: coda's use of file->f_mapping and inode->i_mapping
Date: Wed, 02 Aug 2017 11:05:31 -0400 [thread overview]
Message-ID: <1501686331.4654.6.camel@redhat.com> (raw)
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>
next reply other threads:[~2017-08-02 15:05 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-02 15:05 Jeff Layton [this message]
2017-08-02 15:05 ` coda's use of file->f_mapping and inode->i_mapping Jeff Layton
2017-08-02 20:43 ` Jan Harkes
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1501686331.4654.6.camel@redhat.com \
--to=jlayton@redhat.com \
--cc=coda@cs.cmu.edu \
--cc=codalist@coda.cs.cmu.edu \
--cc=dhowells@redhat.com \
--cc=jaharkes@cs.cmu.edu \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.