From: Dave Chinner <david@fromorbit.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Chris Mason <chris.mason@fusionio.com>,
Chris Mason <clmason@fusionio.com>,
Mikulas Patocka <mpatocka@redhat.com>,
Al Viro <viro@zeniv.linux.org.uk>, Jens Axboe <axboe@kernel.dk>,
Jeff Chua <jeff.chua.linux@gmail.com>,
Lai Jiangshan <laijs@cn.fujitsu.com>, Jan Kara <jack@suse.cz>,
lkml <linux-kernel@vger.kernel.org>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: [PATCH v2] Do a proper locking for mmap and block size change
Date: Sat, 1 Dec 2012 09:40:41 +1100 [thread overview]
Message-ID: <20121130224041.GD12955@dastard> (raw)
In-Reply-To: <20121130163601.GA32238@infradead.org>
On Fri, Nov 30, 2012 at 11:36:01AM -0500, Christoph Hellwig wrote:
> On Fri, Nov 30, 2012 at 01:49:10PM +1100, Dave Chinner wrote:
> > > Ugh. That's a big violation of how buffer-heads are supposed to work:
> > > the block number is very much defined to be in multiples of b_size
> > > (see for example "submit_bh()" that turns it into a sector number).
> > >
> > > But you're right. The direct-IO code really *is* violating that, and
> > > knows that get_block() ends up being defined in i_blkbits regardless
> > > of b_size.
> >
> > Same with mpage_readpages(), so it's not just direct IO that has
> > this problem....
>
> The mpage code may actually fall back to BHs.
>
> I have a version of the direct I/O code that uses the iomap_ops from the
> multi-page write code that you originally started. It uses the new op
> as primary interface for direct I/O and provides a helper for
> filesystems that still use buffer heads internally. I'll try to dust it
> off and send out a version for the current kernel.
So it was based on this interface?
(I went looking for this code on google a couple of days ago so I
could point at it and say "we should be using an iomap structure,
not buffer heads", but it looks like I never posted it to fsdevel or
the xfs lists...)
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 090f0ea..e247d62 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -522,6 +522,7 @@ enum positive_aop_returns {
struct page;
struct address_space;
struct writeback_control;
+struct iomap;
struct iov_iter {
const struct iovec *iov;
@@ -614,6 +615,9 @@ struct address_space_operations {
int (*is_partially_uptodate) (struct page *, read_descriptor_t *,
unsigned long);
int (*error_remove_page)(struct address_space *, struct page *);
+
+ int (*iomap)(struct address_space *mapping, loff_t pos,
+ ssize_t length, struct iomap *iomap, int cmd);
};
/*
diff --git a/include/linux/iomap.h b/include/linux/iomap.h
new file mode 100644
index 0000000..7708614
--- /dev/null
+++ b/include/linux/iomap.h
@@ -0,0 +1,45 @@
+#ifndef _IOMAP_H
+#define _IOMAP_H
+
+/* ->iomap a_op command types */
+#define IOMAP_READ 0x01 /* read the current mapping starting at the
+ given position, trimmed to a maximum length.
+ FS's should use this to obtain and lock
+ resources within this range */
+#define IOMAP_RESERVE 0x02 /* reserve space for an allocation that spans
+ the given iomap */
+#define IOMAP_ALLOCATE 0x03 /* allocate space in a given iomap - must have
+ first been reserved */
+#define IOMAP_UNRESERVE 0x04 /* return unused reserved space for the given
+ iomap and used space. This will always be
+ called after a IOMAP_READ so as to allow the
+ FS to release held resources. */
+
+/* types of block ranges for multipage write mappings. */
+#define IOMAP_HOLE 0x01 /* no blocks allocated, need allocation */
+#define IOMAP_DELALLOC 0x02 /* delayed allocation blocks */
+#define IOMAP_MAPPED 0x03 /* blocks allocated @blkno */
+#define IOMAP_UNWRITTEN 0x04 /* blocks allocated @blkno in unwritten state */
+
+struct iomap {
+ sector_t blkno; /* first sector of mapping */
+ loff_t offset; /* file offset of mapping, bytes */
+ ssize_t length; /* length of mapping, bytes */
+ int type; /* type of mapping */
+ void *priv; /* fs private data associated with map */
+};
+
+static inline bool
+iomap_needs_allocation(struct iomap *iomap)
+{
+ return iomap->type == IOMAP_HOLE;
+}
+
+/* multipage write interfaces use iomaps */
+typedef int (*mpw_actor_t)(struct address_space *mapping, void *src,
+ loff_t pos, ssize_t len, struct iomap *iomap);
+
+ssize_t multipage_write_segment(struct address_space *mapping, void *src,
+ loff_t pos, ssize_t length, mpw_actor_t actor);
+
+#endif /* _IOMAP_H */
Cheers,
Dave.
>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
>
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2012-11-30 22:40 UTC|newest]
Thread overview: 82+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-19 0:33 Recent kernel "mount" slow Jeff Chua
2012-11-20 18:09 ` Jan Kara
2012-11-21 15:46 ` Jeff Chua
2012-11-22 14:30 ` Jeff Chua
2012-11-22 19:21 ` Linus Torvalds
2012-11-23 13:24 ` Jens Axboe
2012-11-23 22:21 ` Jeff Chua
2012-11-23 23:31 ` Jeff Chua
2012-11-23 23:48 ` Jeff Chua
2012-11-24 21:09 ` Mikulas Patocka
2012-11-24 23:23 ` Jeff Chua
2012-11-27 5:57 ` Jeff Chua
2012-11-27 7:38 ` Jens Axboe
2012-11-27 7:44 ` Jens Axboe
2012-11-27 8:45 ` Jeff Chua
2012-11-27 10:06 ` Jeff Chua
2012-11-27 12:33 ` Jens Axboe
2012-11-28 3:57 ` Mikulas Patocka
2012-11-28 8:33 ` Jens Axboe
2012-11-28 13:05 ` Jeff Chua
2012-11-28 17:25 ` [PATCH] Introduce a method to catch mmap_region (was: Recent kernel "mount" slow) Mikulas Patocka
2012-11-28 19:15 ` Linus Torvalds
2012-11-28 19:43 ` Al Viro
2012-11-28 19:53 ` Linus Torvalds
2012-11-28 22:01 ` [PATCH v2] Do a proper locking for mmap and block size change Mikulas Patocka
2012-11-29 17:19 ` Linus Torvalds
2012-11-29 18:23 ` Mikulas Patocka
2012-11-29 18:46 ` Linus Torvalds
2012-11-29 19:02 ` Linus Torvalds
2012-11-29 19:15 ` Chris Mason
2012-11-29 19:26 ` Linus Torvalds
2012-11-29 19:48 ` Chris Mason
2012-11-29 19:55 ` Linus Torvalds
2012-11-29 20:10 ` Linus Torvalds
2012-11-29 20:52 ` Linus Torvalds
2012-11-29 21:29 ` Chris Mason
2012-11-29 22:16 ` Linus Torvalds
2012-11-29 22:36 ` Linus Torvalds
2012-11-30 1:16 ` Chris Mason
2012-11-30 2:13 ` Linus Torvalds
2012-11-30 2:27 ` Chris Mason
2012-11-30 2:49 ` Dave Chinner
2012-11-30 14:31 ` Chris Mason
2012-11-30 16:42 ` Linus Torvalds
2012-11-30 16:36 ` Christoph Hellwig
2012-11-30 22:40 ` Dave Chinner [this message]
2012-11-30 23:09 ` Christoph Hellwig
2012-11-29 19:50 ` Linus Torvalds
2012-11-28 19:50 ` [PATCH] Introduce a method to catch mmap_region (was: Recent kernel "mount" slow) Mikulas Patocka
2012-11-28 20:03 ` Linus Torvalds
2012-11-28 20:13 ` Linus Torvalds
2012-11-28 20:32 ` Linus Torvalds
2012-11-28 20:47 ` Linus Torvalds
2012-11-28 22:10 ` Mikulas Patocka
2012-11-28 21:29 ` Mikulas Patocka
2012-11-28 22:52 ` Linus Torvalds
2012-11-28 23:13 ` Linus Torvalds
2012-11-29 1:20 ` Mikulas Patocka
2012-11-29 0:38 ` Mikulas Patocka
2012-11-29 2:04 ` Linus Torvalds
2012-11-29 2:58 ` Linus Torvalds
2012-11-29 6:16 ` Linus Torvalds
2012-11-29 6:25 ` Al Viro
2012-11-29 6:30 ` Al Viro
2012-11-29 6:37 ` Linus Torvalds
2012-11-29 6:45 ` Al Viro
2012-11-29 10:57 ` Jeff Chua
2012-11-29 6:33 ` Linus Torvalds
2012-11-29 14:12 ` Chris Mason
2012-11-29 17:26 ` Chris Mason
2012-11-29 17:26 ` Linus Torvalds
2012-11-29 17:51 ` Chris Mason
2012-11-29 18:12 ` Linus Torvalds
2012-11-28 3:59 ` [PATCH 1/2] percpu-rwsem: use synchronize_sched_expedited Mikulas Patocka
2012-11-28 4:01 ` [PATCH 2/2] block_dev: don't take the write lock if block size doesn't change Mikulas Patocka
2012-11-28 14:24 ` Jeff Chua
2012-11-28 22:03 ` Mikulas Patocka
2012-11-28 14:19 ` [PATCH 1/2] percpu-rwsem: use synchronize_sched_expedited Jeff Chua
2012-11-30 0:06 ` Andrew Morton
2012-11-30 3:00 ` Mikulas Patocka
2012-11-30 13:42 ` Paul E. McKenney
2012-11-30 18:57 ` Oleg Nesterov
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=20121130224041.GD12955@dastard \
--to=david@fromorbit.com \
--cc=axboe@kernel.dk \
--cc=chris.mason@fusionio.com \
--cc=clmason@fusionio.com \
--cc=hch@infradead.org \
--cc=jack@suse.cz \
--cc=jeff.chua.linux@gmail.com \
--cc=laijs@cn.fujitsu.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mpatocka@redhat.com \
--cc=torvalds@linux-foundation.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.