Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1347770 > unrolled thread
| Started by | "Darrick J. Wong" <darrick.wong@oracle.com> |
|---|---|
| First post | 2016-03-02 05:20 +0100 |
| Last post | 2016-03-02 12:00 +0100 |
| Articles | 8 on this page of 68 — 16 participants |
Back to article view | Back to linux.kernel
[PATCH v5.1 0/2] create BLKZEROOUT ioctl that invalidates page cache "Darrick J. Wong" <darrick.wong@oracle.com> - 2016-03-02 05:20 +0100
[PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks "Darrick J. Wong" <darrick.wong@oracle.com> - 2016-03-02 05:20 +0100
Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks Christoph Hellwig <hch@infradead.org> - 2016-03-02 10:30 +0100
Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks Linus Torvalds <torvalds@linux-foundation.org> - 2016-03-02 20:00 +0100
Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks "Darrick J. Wong" <darrick.wong@oracle.com> - 2016-03-03 00:00 +0100
Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks Linus Torvalds <torvalds@linux-foundation.org> - 2016-03-03 01:00 +0100
Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks Theodore Ts'o <tytso@mit.edu> - 2016-03-03 18:10 +0100
Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks Linus Torvalds <torvalds@linux-foundation.org> - 2016-03-03 19:00 +0100
Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks Christoph Hellwig <hch@infradead.org> - 2016-03-03 19:10 +0100
Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks "Martin K. Petersen" <martin.petersen@oracle.com> - 2016-03-03 19:20 +0100
Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks Theodore Ts'o <tytso@mit.edu> - 2016-03-03 19:30 +0100
Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks "Martin K. Petersen" <martin.petersen@oracle.com> - 2016-03-03 19:10 +0100
Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks Christoph Hellwig <hch@infradead.org> - 2016-03-03 19:10 +0100
Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks "Darrick J. Wong" <darrick.wong@oracle.com> - 2016-03-03 19:20 +0100
Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks "Martin K. Petersen" <martin.petersen@oracle.com> - 2016-03-03 20:00 +0100
Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks Theodore Ts'o <tytso@mit.edu> - 2016-03-03 23:50 +0100
Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks Dave Chinner <david@fromorbit.com> - 2016-03-04 00:20 +0100
Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks Theodore Ts'o <tytso@mit.edu> - 2016-03-04 01:30 +0100
Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks Gregory Farnum <greg@gregs42.com> - 2016-03-09 23:30 +0100
Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks Theodore Ts'o <tytso@mit.edu> - 2016-03-10 00:10 +0100
Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks Ric Wheeler <ricwheeler@gmail.com> - 2016-03-10 16:00 +0100
Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks Linus Torvalds <torvalds@linux-foundation.org> - 2016-03-10 19:40 +0100
Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks Theodore Ts'o <tytso@mit.edu> - 2016-03-10 22:50 +0100
Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks Ric Wheeler <rwheeler@redhat.com> - 2016-03-11 05:50 +0100
Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> - 2016-03-11 15:10 +0100
Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks Theodore Ts'o <tytso@mit.edu> - 2016-03-11 16:30 +0100
Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks Linus Torvalds <torvalds@linux-foundation.org> - 2016-03-11 18:30 +0100
Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks Andy Lutomirski <luto@amacapital.net> - 2016-03-11 18:40 +0100
Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks Linus Torvalds <torvalds@linux-foundation.org> - 2016-03-11 19:30 +0100
Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks Dave Chinner <david@fromorbit.com> - 2016-03-11 23:40 +0100
Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks Theodore Ts'o <tytso@mit.edu> - 2016-03-12 01:40 +0100
Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks Linus Torvalds <torvalds@linux-foundation.org> - 2016-03-12 01:50 +0100
Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks Theodore Ts'o <tytso@mit.edu> - 2016-03-12 08:30 +0100
Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks Thomas Schoebel-Theuer <tst@schoebel-theuer.de> - 2016-03-12 11:20 +0100
Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks Dave Chinner <david@fromorbit.com> - 2016-03-14 00:40 +0100
Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks Ric Wheeler <rwheeler@redhat.com> - 2016-03-14 11:40 +0100
Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks Theodore Ts'o <tytso@mit.edu> - 2016-03-14 15:50 +0100
Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks Dave Chinner <david@fromorbit.com> - 2016-03-15 21:20 +0100
Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks Linus Torvalds <torvalds@linux-foundation.org> - 2016-03-15 21:50 +0100
Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks Theodore Ts'o <tytso@mit.edu> - 2016-03-15 22:30 +0100
Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks Dave Chinner <david@fromorbit.com> - 2016-03-15 23:40 +0100
Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks Theodore Ts'o <tytso@mit.edu> - 2016-03-16 00:00 +0100
Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks "Darrick J. Wong" <darrick.wong@oracle.com> - 2016-03-16 03:00 +0100
Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks Andreas Dilger <adilger@dilger.ca> - 2016-03-16 22:50 +0100
Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks Theodore Ts'o <tytso@mit.edu> - 2016-03-17 01:20 +0100
Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks Eric Sandeen <esandeen@redhat.com> - 2016-03-17 01:40 +0100
Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks Theodore Ts'o <tytso@mit.edu> - 2016-03-17 02:00 +0100
Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks Gregory Farnum <greg@gregs42.com> - 2016-03-17 06:20 +0100
Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks Theodore Ts'o <tytso@mit.edu> - 2016-03-17 13:40 +0100
Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks Dave Chinner <david@fromorbit.com> - 2016-03-17 02:10 +0100
Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks "Darrick J. Wong" <darrick.wong@oracle.com> - 2016-03-17 03:50 +0100
Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks Linus Torvalds <torvalds@linux-foundation.org> - 2016-03-16 00:10 +0100
Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks Linus Torvalds <torvalds@linux-foundation.org> - 2016-03-16 00:20 +0100
Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks Dave Chinner <david@fromorbit.com> - 2016-03-16 01:10 +0100
Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks Dave Chinner <david@fromorbit.com> - 2016-03-16 01:00 +0100
Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks Linus Torvalds <torvalds@linux-foundation.org> - 2016-03-16 01:10 +0100
Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks Eric Sandeen <esandeen@redhat.com> - 2016-03-16 01:40 +0100
Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks Chris Mason <clm@fb.com> - 2016-03-16 02:00 +0100
Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks Chris Mason <clm@fb.com> - 2016-03-16 23:30 +0100
Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks Ric Wheeler <rwheeler@redhat.com> - 2016-03-17 14:50 +0100
Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks Eric Sandeen <esandeen@redhat.com> - 2016-03-15 23:40 +0100
Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks Linus Torvalds <torvalds@linux-foundation.org> - 2016-03-12 01:40 +0100
Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks Dave Chinner <david@fromorbit.com> - 2016-03-04 00:00 +0100
Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks Thomas Schoebel-Theuer <tst@schoebel-theuer.de> - 2016-03-04 03:40 +0100
Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks Linus Torvalds <torvalds@linux-foundation.org> - 2016-03-03 19:20 +0100
Re: [PATCH v5.1 0/2] create BLKZEROOUT ioctl that invalidates page cache Arnd Bergmann <arnd@arndb.de> - 2016-03-02 10:20 +0100
Re: [PATCH v5.1 0/2] create BLKZEROOUT ioctl that invalidates page cache Christoph Hellwig <hch@infradead.org> - 2016-03-02 10:50 +0100
Re: [PATCH v5.1 0/2] create BLKZEROOUT ioctl that invalidates page cache Arnd Bergmann <arnd@arndb.de> - 2016-03-02 12:00 +0100
Page 4 of 4 — ← Prev page 1 2 3 [4]
| From | Eric Sandeen <esandeen@redhat.com> |
|---|---|
| Date | 2016-03-15 23:40 +0100 |
| Subject | Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks |
| Message-ID | <rd5N7-8tc-5@gated-at.bofh.it> |
| In reply to | #1358224 |
On 3/15/16 3:14 PM, Dave Chinner wrote: > What we are missing is actual numbers that show that exposing stale > data is a /significant/ win for these applications that are > demanding it. And then we need evidence proving that the problem is > actually systemic and not just a hack around a bad implementation of > a feature... Thanks Dave; I totally agree on this point. We've spent more than enough time talking about how and if to implement stale data exposure, but nowhere in this thread has there been any actual performance data indicating why we should do it at all. -Eric
[toc] | [prev] | [next] | [standalone]
| From | Linus Torvalds <torvalds@linux-foundation.org> |
|---|---|
| Date | 2016-03-12 01:40 +0100 |
| Subject | Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks |
| Message-ID | <rbFL3-63Y-3@gated-at.bofh.it> |
| In reply to | #1356243 |
On Fri, Mar 11, 2016 at 2:30 PM, Dave Chinner <david@fromorbit.com> wrote:
> On Fri, Mar 11, 2016 at 10:25:30AM -0800, Linus Torvalds wrote:
>>
>> So you'd have to explicitly say "my setup is ok with hole punching".
>
> Except it's not hole punching that is the problem. [..]
> The problem here is
> preallocation of unwritten blocks that expose the stale data if the
> filesystem skips marking those blocks as unwritten.
Right you are.
> It's all well and good to restrict access to the fallocate() call to
> limit who can expose stale data, but it doesn't remove the fact it
> is easy for stale data to unintentionally escape the privileged
> group once it has been exposed because there is no record of the
> fact the file contains uninitialised blocks....
Good point.
It's not just that the user in question *couldn't* have exposed it
other ways by reading the raw device and then writing that info into a
file. You're right that the "don't initialize unwritten blocks" thing
has a more insidious problem of making it easy to unintentionally
expose such data just because you missed an error path (or the process
died without ever doing the proper over-write)..
It would be much better if we could somehow mitigate just _how_ easy
it is to screw up.
One way to do that would be to not just require that the user that
discards the initializing writes have read access to the underlying
device, but perhaps also have some strict requirement that you can
discard only if the file you are working with is legible only to you?
That would limit the damage, and keep the stale data "private" to the
user who is already able to read the raw data off the device. Sure,
you can then mark the file read-by-world by others later, but at that
point you're kind of *consciously* exposing that stale data (and at
that point, you have hopefully cleaned it all up and replaced the
stale data with real data).
But would that perhaps not be reasonable for the kind of use cases
that google has now?
Linus
[toc] | [prev] | [next] | [standalone]
| From | Dave Chinner <david@fromorbit.com> |
|---|---|
| Date | 2016-03-04 00:00 +0100 |
| Subject | Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks |
| Message-ID | <r8KnU-5IL-23@gated-at.bofh.it> |
| In reply to | #1349482 |
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
[toc] | [prev] | [next] | [standalone]
| From | Thomas Schoebel-Theuer <tst@schoebel-theuer.de> |
|---|---|
| Date | 2016-03-04 03:40 +0100 |
| Subject | Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks |
| Message-ID | <r8NON-8h2-1@gated-at.bofh.it> |
| In reply to | #1349674 |
On 03/03/2016 11:56 PM, Dave Chinner wrote: > 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. This would advocate a uniform /internal/ interface (family) across both fs and block layers, similiar in spirit to my old Athomux research prototype long ago (see www.athomux.net). This allows for recursive nesting in complex (distributed) storage/fs hierarchies. It would be nice if that internal interface (family) would be (partly / fully) asynchronous with callbacks. In ideal case, it should be compatible with workqueues (no need for blocking threads anymore). Uniformity is only needed at concept level. There might remain different flavours of concrete interfaces at different subsystems, if the number of subsystems remains as small as possible, and interfacing is close to trivial. I would like to support this also in future versions of MARS (see github.com/schoebel/mars). Cheers, Thomas
[toc] | [prev] | [next] | [standalone]
| From | Linus Torvalds <torvalds@linux-foundation.org> |
|---|---|
| Date | 2016-03-03 19:20 +0100 |
| Subject | Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks |
| Message-ID | <r8G0W-2zu-21@gated-at.bofh.it> |
| In reply to | #1349461 |
On Thu, Mar 3, 2016 at 10:01 AM, Martin K. Petersen
<martin.petersen@oracle.com> wrote:
>>>>>> "Linus" == Linus Torvalds <torvalds@linux-foundation.org> writes:
>
> Linus> .. but the flag doesn't even set that. Even if you avoid TRIM,
> Linus> there is absolutely zero guarantees that WRITE_SAME would do
> Linus> "real storage blocks full of zeroes backing the LBAs they just
> Linus> wrote out".
>
> That's not entirely true. Writing the blocks may cause them to be
> allocated on the storage device (depending on which flags we feed it in
> WRITE SAME).
Ok, so now we're getting somewhere, with actual _reasons_ why somebody
would want to use one interface over another.
> The filesystems people were wanted the following semantics:
>
> - deallocate, don't care about contents for future reads (discard)
> - deallocate, guarantee zeroes on future reads (zeroout)
> - (re)allocate, guarantee zeroes on future reads (zeroout)
>
> Maybe we just need a better naming scheme...
Yes.
And this does make me think that Christoph is right: this would be so
much better if the block layer just supported fallocate() instead,
which already has those operations.
Right now we have
if (!S_ISREG(inode->i_mode) && !S_ISDIR(inode->i_mode))
return -ENODEV;
so right now the vfs_fallocate() code expliitly disallows block
devices, but that would be easy to expand.
Would people be happy with that kind of patch instead? It would
certainly make all my objections go away..
Linus
[toc] | [prev] | [next] | [standalone]
| From | Arnd Bergmann <arnd@arndb.de> |
|---|---|
| Date | 2016-03-02 10:20 +0100 |
| Message-ID | <r8b6O-5Co-21@gated-at.bofh.it> |
| In reply to | #1347770 |
On Tuesday 01 March 2016 20:09:32 Darrick J. Wong wrote: > This is (yet another) repost of the patch series that fixes the > existing BLKZEROOUT ioctl to invalidate the page cache if the zeroing > command to the underlying device succeeds. This patch is against > 4.5-rc6 and hasn't changed much in months. > > The new BLKZEROOUT ioctl has the same semantics as the old one, but it > invalidates the page cache to prevent surprising results, just like > how dio writes invalidate page cache. > > I've incorporated all the feedback I've received into these patches, > but haven't heard yea or nay or anything at all from the maintainer. > Will someone please pick this up for 4.6? > > Comments and questions are, as always, welcome. I'm missing the background on this, just saw the patch fly by, so sorry if this has been asked before: Why do you want to invalidate the cache? Is this to save RAM or is something else going to write here and you have to invalidate it for correctness? If you just want to save RAM, would it be possible to instead point the page cache to the empty zero page to speed up subsequent reads? Maybe that just causes more complexity than it helps. Arnd
[toc] | [prev] | [next] | [standalone]
| From | Christoph Hellwig <hch@infradead.org> |
|---|---|
| Date | 2016-03-02 10:50 +0100 |
| Subject | Re: [PATCH v5.1 0/2] create BLKZEROOUT ioctl that invalidates page cache |
| Message-ID | <r8bzQ-5NZ-11@gated-at.bofh.it> |
| In reply to | #1347875 |
On Wed, Mar 02, 2016 at 10:15:02AM +0100, Arnd Bergmann wrote: > I'm missing the background on this, just saw the patch fly by, > so sorry if this has been asked before: > > Why do you want to invalidate the cache? Is this to save RAM > or is something else going to write here and you have to invalidate > it for correctness? BLKZEROOUT can be though as a direct I/O operation - it issues a WRITE SAME (or similar) command straight to the device to zero the specified range. If there was cached data for this range it would now be stale.
[toc] | [prev] | [next] | [standalone]
| From | Arnd Bergmann <arnd@arndb.de> |
|---|---|
| Date | 2016-03-02 12:00 +0100 |
| Message-ID | <r8cFA-6tO-1@gated-at.bofh.it> |
| In reply to | #1347899 |
On Wednesday 02 March 2016 01:44:16 Christoph Hellwig wrote: > On Wed, Mar 02, 2016 at 10:15:02AM +0100, Arnd Bergmann wrote: > > I'm missing the background on this, just saw the patch fly by, > > so sorry if this has been asked before: > > > > Why do you want to invalidate the cache? Is this to save RAM > > or is something else going to write here and you have to invalidate > > it for correctness? > > BLKZEROOUT can be though as a direct I/O operation - it issues a > WRITE SAME (or similar) command straight to the device to zero > the specified range. If there was cached data for this range it would > now be stale. Ok, got it. Thanks, Arnd
[toc] | [prev] | [standalone]
Page 4 of 4 — ← Prev page 1 2 3 [4]
Back to top | Article view | linux.kernel
csiph-web