From: Dave Chinner <david@fromorbit.com>
To: "Martin K. Petersen" <martin.petersen@oracle.com>
Cc: Christoph Hellwig <hch@infradead.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
"Darrick J. Wong" <darrick.wong@oracle.com>,
Jens Axboe <axboe@kernel.dk>,
Andrew Morton <akpm@linux-foundation.org>,
Linux API <linux-api@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
shane.seymour@hpe.com, Bruce Fields <bfields@fieldses.org>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
Jeff Layton <jlayton@poochiereds.net>
Subject: Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks
Date: Fri, 4 Mar 2016 09:56:46 +1100 [thread overview]
Message-ID: <20160303225646.GT29057@dastard> (raw)
In-Reply-To: <yq1vb5375oh.fsf@sermon.lab.mkp.net>
On Thu, Mar 03, 2016 at 01:54:54PM -0500, Martin K. Petersen wrote:
> >>>>> "Christoph" == Christoph Hellwig <hch@infradead.org> writes:
>
> Christoph> - FALLOC_FL_PUNCH_HOLE assures zeroes are returned, but
> Christoph> space is deallocated as much as possible -
> Christoph> FALLOC_FL_ZERO_RANGE assures zeroes are returned, AND blocks
> Christoph> are actually allocated
>
> That works for me. I think it would be great if we could have consistent
> interfaces for fs and block. The more commonality the merrier.
Absolutely in agreement here. it would be much nicer if filesystems
could just call bdev->ops->fallocate(PUNCH_HOLE, off, len) and
bdev->ops->fallocate(ZERO_RANGE, off, len) than all the weird
"technology specific" blkdev_issue_foo() functions we have grown
over time. Let the block device implement them as it sees fit - the
higher levels don't need to care about protocol/technology details.
---
FWIW, this reminds me of a "bigger picture" I think we should
be working towards. Does anyone remember this:
https://lwn.net/Articles/592091/
(Splitting filesytems in two)
i.e. if we add fallocate support to punch holes, zero ranges and
*allocate blocks* to a block device, we're mostly at the point where
we can offload all freespace management that the filesystem
currently does to the underlying block device.
There's really only a small extension we'd need - the block
allocation done by the block device needs to be able to return the
the sector and length of the newly allocated extent. Indeed, this is
something we talked about last year at LSFMM as a solution to the
SMR write ordering problem:
https://lwn.net/Articles/637035/
(near the end, paragraph talking about a "new kind of write command")
That "new kind of write command" would enable delayed allocation
algorithms to continue to work at the filesystem level on block
devices that freespace management completely is offloaded to...
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2016-03-03 22:57 UTC|newest]
Thread overview: 82+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-02 4:09 [PATCH v5.1 0/2] create BLKZEROOUT ioctl that invalidates page cache Darrick J. Wong
2016-03-02 4:09 ` [PATCH 1/2] block: invalidate the page cache when issuing BLKZEROOUT Darrick J. Wong
2016-03-02 9:19 ` Christoph Hellwig
2016-03-02 4:09 ` [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks Darrick J. Wong
2016-03-02 9:20 ` Christoph Hellwig
2016-03-02 18:52 ` Linus Torvalds
2016-03-02 22:56 ` Darrick J. Wong
2016-03-02 23:49 ` Linus Torvalds
2016-03-03 17:02 ` Theodore Ts'o
2016-03-03 17:55 ` Linus Torvalds
2016-03-03 18:00 ` Christoph Hellwig
2016-03-03 18:14 ` Martin K. Petersen
2016-03-03 18:21 ` Theodore Ts'o
2016-03-03 18:01 ` Martin K. Petersen
2016-03-03 18:09 ` Christoph Hellwig
2016-03-03 18:12 ` Darrick J. Wong
2016-03-03 18:54 ` Martin K. Petersen
2016-03-03 22:39 ` Theodore Ts'o
2016-03-03 23:10 ` Dave Chinner
2016-03-04 0:20 ` Theodore Ts'o
2016-03-09 22:20 ` Gregory Farnum
2016-03-09 23:08 ` Theodore Ts'o
2016-03-10 14:58 ` Ric Wheeler
2016-03-10 18:33 ` Linus Torvalds
2016-03-10 21:47 ` Theodore Ts'o
2016-03-11 4:42 ` Ric Wheeler
2016-03-11 13:59 ` One Thousand Gnomes
2016-03-11 15:27 ` Theodore Ts'o
2016-03-11 17:23 ` Linus Torvalds
2016-03-11 17:30 ` Andy Lutomirski
2016-03-11 18:25 ` Linus Torvalds
2016-03-11 22:30 ` Dave Chinner
2016-03-12 0:33 ` Linus Torvalds
2016-03-12 0:35 ` Theodore Ts'o
2016-03-12 0:44 ` Linus Torvalds
2016-03-12 7:19 ` Theodore Ts'o
2016-03-12 10:11 ` Thomas Schoebel-Theuer
2016-03-13 23:30 ` Dave Chinner
2016-03-14 10:34 ` Ric Wheeler
2016-03-14 14:46 ` Theodore Ts'o
2016-03-15 20:14 ` Dave Chinner
2016-03-15 20:43 ` Linus Torvalds
2016-03-15 21:29 ` Theodore Ts'o
2016-03-15 22:33 ` Dave Chinner
2016-03-15 22:52 ` Theodore Ts'o
2016-03-16 1:51 ` Darrick J. Wong
2016-03-16 21:45 ` Andreas Dilger
2016-03-17 0:15 ` Theodore Ts'o
2016-03-17 0:33 ` Eric Sandeen
2016-03-17 0:59 ` Theodore Ts'o
2016-03-17 5:18 ` Gregory Farnum
2016-03-17 12:36 ` Theodore Ts'o
2016-03-17 17:47 ` Linus Torvalds
2016-03-17 17:50 ` Ric Wheeler
2016-03-17 17:59 ` Linus Torvalds
2016-03-17 18:35 ` Chris Mason
2016-03-17 20:49 ` Andreas Dilger
2016-03-17 21:00 ` Chris Mason
2016-03-18 3:20 ` Theodore Ts'o
2016-03-18 15:15 ` Jeff Moyer
2016-03-18 20:05 ` Martin K. Petersen
2016-03-18 6:52 ` Gregory Farnum
2016-03-18 7:19 ` Linus Torvalds
2016-03-17 1:01 ` Dave Chinner
2016-03-17 2:38 ` Darrick J. Wong
2016-03-18 22:55 ` NeilBrown
2016-03-15 23:06 ` Linus Torvalds
2016-03-15 23:14 ` Linus Torvalds
2016-03-16 0:08 ` Dave Chinner
2016-03-15 23:52 ` Dave Chinner
2016-03-16 0:06 ` Linus Torvalds
2016-03-16 0:30 ` Eric Sandeen
2016-03-16 0:51 ` Chris Mason
2016-03-16 22:23 ` Chris Mason
2016-03-17 13:49 ` Ric Wheeler
2016-03-15 22:38 ` Eric Sandeen
2016-03-03 22:56 ` Dave Chinner [this message]
2016-03-04 2:30 ` Thomas Schoebel-Theuer
2016-03-03 18:14 ` Linus Torvalds
2016-03-02 9:15 ` [PATCH v5.1 0/2] create BLKZEROOUT ioctl that invalidates page cache Arnd Bergmann
2016-03-02 9:44 ` Christoph Hellwig
2016-03-02 10:55 ` Arnd Bergmann
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=20160303225646.GT29057@dastard \
--to=david@fromorbit.com \
--cc=akpm@linux-foundation.org \
--cc=axboe@kernel.dk \
--cc=bfields@fieldses.org \
--cc=darrick.wong@oracle.com \
--cc=hch@infradead.org \
--cc=jlayton@poochiereds.net \
--cc=linux-api@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=shane.seymour@hpe.com \
--cc=torvalds@linux-foundation.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).