On Tue, Oct 7, 2014 at 3:16 PM, Jan Kara wrote:
> On Tue 07-10-14 12:30:59, Dave Chinner wrote:
>> On Mon, Oct 06, 2014 at 04:30:19PM +0200, Jan Kara wrote:
>> > On Mon 06-10-14 11:33:23, Thanos Makatos wrote:
>> > > > > Trond also had a comment that if we extended the ioctl to work for
>> > > >
On Tue 07-10-14 12:30:59, Dave Chinner wrote:
> On Mon, Oct 06, 2014 at 04:30:19PM +0200, Jan Kara wrote:
> > On Mon 06-10-14 11:33:23, Thanos Makatos wrote:
> > > > > Trond also had a comment that if we extended the ioctl to work for all
> > > > > inodes (not just blkdev) and allowed some addition
On Mon, Oct 06, 2014 at 04:30:19PM +0200, Jan Kara wrote:
> On Mon 06-10-14 11:33:23, Thanos Makatos wrote:
> > > > Trond also had a comment that if we extended the ioctl to work for all
> > > > inodes (not just blkdev) and allowed some additional flags of what
> > > > needs to be invalidated, the
Thanks, Jan, it's much clearer now what I need to do.
> So most notably they want the ioctl to work not only for block devices but
> also for any regular file. That's easily doable - you just call
> filemap_write_and_wait() and invalidate_inode_pages2() in the ioctl handler
> for regular files
On Mon 06-10-14 11:33:23, Thanos Makatos wrote:
> > > Trond also had a comment that if we extended the ioctl to work for all
> > > inodes (not just blkdev) and allowed some additional flags of what
> > > needs to be invalidated, the new ioctl would be also useful to NFS
> > > userspace - see Trond'
> > Trond also had a comment that if we extended the ioctl to work for all
> > inodes (not just blkdev) and allowed some additional flags of what
> > needs to be invalidated, the new ioctl would be also useful to NFS
> > userspace - see Trond's email at
> >
> > http://www.spinics.net/lists/linux-fs
> > We're currently ignoring the buffer cache sync and invalidation (which
> > is odd), but at least being consistent would be good.
> Well, invalidate_bdev() doesn't return anything. And
> invalidate_mapping_pages() inside invalidate_bdev() returns only number of
> invalidated pages. I don't thi
On Thu 02-10-14 13:59:40, Jens Axboe wrote:
> On 10/02/2014 10:09 AM, Thanos Makatos wrote:
> > This patch introduces a new ioctl called BLKFLUSHBUFS2, which is pretty
> > similar to BLKFLUSHBUFS except that is also invalidates the page cache.
> > This allows for a complete invalidation of the cach
On 2014-10-03 03:25, Thanos Makatos wrote:
- fsync_bdev(bdev);
- invalidate_bdev(bdev);
+ flush_buffer_cache(bdev);
+ if (BLKFLSBUF2 == cmd)
+ return invalidate_inode_pages2(
+ bdev
> > - fsync_bdev(bdev);
> > - invalidate_bdev(bdev);
> > + flush_buffer_cache(bdev);
> > + if (BLKFLSBUF2 == cmd)
> > + return invalidate_inode_pages2(
> > + bdev->bd_inode->i_mapping);
> > retur
> > > This patch introduces a new ioctl called BLKFLUSHBUFS2, which is
> > > pretty
>
> What a horrible name. Whatever happened to naming ioctls interfaces after
> their function? i.e. BLKFLUSHINVAL?
Indeed it's not a good name, I'm open to suggestions!
--
To unsubscribe from this list: send the
On Thu, Oct 02, 2014 at 01:59:40PM -0600, Jens Axboe wrote:
> On 10/02/2014 10:09 AM, Thanos Makatos wrote:
> > This patch introduces a new ioctl called BLKFLUSHBUFS2, which is pretty
What a horrible name. Whatever happened to naming ioctls interfaces
after their function? i.e. BLKFLUSHINVAL?
Che
On 10/02/2014 10:09 AM, Thanos Makatos wrote:
> This patch introduces a new ioctl called BLKFLUSHBUFS2, which is pretty
> similar to BLKFLUSHBUFS except that is also invalidates the page cache.
> This allows for a complete invalidation of the cached data of a
> particular block device, which might
13 matches
Mail list logo
