linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Josef Bacik <josef@redhat.com>
To: linux-fsdevel@vger.kernel.org, linux-btrfs@vger.kernel.org,
	chris.mason@oracle.com, hch@infradead.org
Subject: [RFC] Add a new file op for fsync to give fs's more control
Date: Fri, 15 Apr 2011 15:09:40 -0400	[thread overview]
Message-ID: <1302894582-24341-1-git-send-email-josef@redhat.com> (raw)

Btrfs needs to be able to control how data is submitted in the case of fsync to
make it a little faster, and really we could get rid of holding the i_mutex
altogether as well.  So introduce a ->fsync_nolock helper that pushes the
responsibility of locking the inode and doing the filemap_write_and_wait_range
down into the fs so we can have better control of how we submit the io and do
our locking.  It looks like ext4 and probably xfs could get away with not taking
the i_mutex either, so they may benefit from this as well.  Really I could just
change ->fsync() to do this and push everything down into all the filesystems,
but I wasn't sure how well that would be recieved, so I'm taking this approach.
Thanks,

Josef

             reply	other threads:[~2011-04-15 19:20 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-15 19:09 Josef Bacik [this message]
2011-04-15 19:09 ` [PATCH 1/2] fs: add a ->fsync_nolock file op Josef Bacik
2011-04-15 19:09 ` [PATCH 2/2] Btrfs: switch to the ->fsync_nolock helper Josef Bacik
2011-04-15 19:24 ` [RFC] Add a new file op for fsync to give fs's more control Christoph Hellwig
2011-04-15 19:32   ` Josef Bacik
2011-04-18  6:49     ` liubo
2011-04-18 14:10       ` Josef Bacik
2011-04-18 14:30       ` Chris Mason
2011-04-15 19:34   ` Chris Mason
2011-04-15 19:49     ` Christoph Hellwig

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=1302894582-24341-1-git-send-email-josef@redhat.com \
    --to=josef@redhat.com \
    --cc=chris.mason@oracle.com \
    --cc=hch@infradead.org \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).