/cgit/linux/kernel/git/axboe/linux-block.git
> dio-mem-align
This patch has been dropped, we did identify last week that btrfs
needs more work to support sub bs memory alignment for dio.
--
Jens Axboe
On 1/26/21 7:52 AM, Christoph Hellwig wrote:
> Hi Jens,
>
> this series contains various cleanups for how bios are allocated or
> initialized plus related fallout.
Applied, thanks.
--
Jens Axboe
On 1/25/21 7:24 PM, Naohiro Aota wrote:
> From: Johannes Thumshirn
>
> Add bio_add_zone_append_page(), a wrapper around bio_add_hw_page() which
> is intended to be used by file systems that directly add pages to a bio
> instead of using bio_iov_iter_get_pages().
>
> Cc: J
ven though that's the name of the syscall.
Agreed, only case we do mimic the names are for things like
IORING_OP_OPENAT2 where it does carry meaning. For this one, it should
just be IORING_OP_GETDENTS.
--
Jens Axboe
On 1/23/21 11:16 AM, Lennert Buytenhek wrote:
> On Sat, Jan 23, 2021 at 10:37:25AM -0700, Jens Axboe wrote:
>
>>> IORING_OP_GETDENTS64 behaves like getdents64(2) and takes the same
>>> arguments.
>>>
>>> Signed-off-by: Lennert Buytenhek
>>>
/when these operations need to go async and finish
out-of-line, the contents are stable and there's no requirement for the
application to keep them valid once submission is done.
Not sure how best to solve that, since the vfs side relies heavily on
linux_dirent64 being a user pointer...
Outside of that, implementation looks straight forward.
--
Jens Axboe
return -EPERM;
>
> How does this capable() check interact with io_uring? Without having
> looked at this in detail, I suspect that when an encoded write is
> requested through io_uring, the capable() check might be executed on
> something like a workqueue worker thread, which is probably running
> with a full capability set.
If we can hit -EAGAIN before doing the import in io_uring, then yes,
this will probably bypass the check as it'll only happen from the
worker.
--
Jens Axboe
On 2/15/19 10:14 AM, Bart Van Assche wrote:
> On Fri, 2019-02-15 at 08:49 -0700, Jens Axboe wrote:
>> On 2/15/19 4:13 AM, Ming Lei wrote:
>>> This patchset brings multi-page bvec into block layer:
>>
>> Applied, thanks Ming. Let's hope it sticks!
>
>
4
^^^
v15?
> Lots of test(blktest, xfstests, ltp io, ...) have been run with this patchset,
> and not see regression.
>
> Thanks Christoph for reviewing the early version and providing very good
> suggestions, such as: introduce bio_init_with_vec_table(), remove another
> unnecessary helpers for cleanup and so on.
>
> Thanks Chritoph and Omar for reviewing V10/V11/V12, and provides lots of
> helpful comments.
Applied, thanks Ming. Let's hope it sticks!
--
Jens Axboe
bvec-V12
>
> Lots of test(blktest, xfstests, ltp io, ...) have been run with this patchset,
> and not see regression.
>
> Thanks Christoph for reviewing the early version and providing very good
> suggestions, such as: introduce bio_init_with_vec_table(), remove another
> unnecessary helpers for cleanup and so on.
>
> Thanks Chritoph and Omar for reviewing V10/V11/V12, and provides lots of
> helpful comments.
Thanks for persisting in this endeavor, Ming, I've applied this for 5.1.
--
Jens Axboe
seems Ewan and Mike is waiting for this fix.
Not familiar with this issue, can you post a link to it? I'd be fine
working around anything until 4.22, it's not going to be a new issue.
--
Jens Axboe
ess the last comments. My only concern is whether
it's a good idea to target this for 4.21, or if we should wait until
4.22. 4.21 has a fairly substantial amount of changes in terms of block
already, it's not the best timing for something of this magnitude too.
I'm going back and forth on those one a bit. Any concerns with
pushing this to 4.22?
--
Jens Axboe
e imho. Don't name these after the fact that they
are done in conjunction with supporting multipage bvecs. That
very fact will be irrelevant very soon
--
Jens Axboe
On 5/21/18 10:09 AM, Mike Snitzer wrote:
> On Mon, May 21 2018 at 11:36am -0400,
> Jens Axboe wrote:
>
>> On 5/21/18 9:18 AM, Mike Snitzer wrote:
>>> On Mon, May 21 2018 at 11:09am -0400,
>>> Jens Axboe wrote:
>>>
>>>> On 5/21/18 9:04 AM, Mi
On 5/21/18 9:18 AM, Mike Snitzer wrote:
> On Mon, May 21 2018 at 11:09am -0400,
> Jens Axboe wrote:
>
>> On 5/21/18 9:04 AM, Mike Snitzer wrote:
>>> On Mon, May 21 2018 at 10:52am -0400,
>>> Jens Axboe wrote:
>>>
>>>> On 5/21/18 8:47 AM, Mi
On 5/21/18 9:12 AM, David Sterba wrote:
> On Mon, May 21, 2018 at 08:19:58AM -0600, Jens Axboe wrote:
>> On 5/21/18 8:03 AM, Mike Snitzer wrote:
>>> On Sun, May 20 2018 at 6:25pm -0400,
>>> Kent Overstreet wrote:
>>>
>>>> Jens - this series does t
On 5/21/18 9:04 AM, Mike Snitzer wrote:
> On Mon, May 21 2018 at 10:52am -0400,
> Jens Axboe wrote:
>
>> On 5/21/18 8:47 AM, Mike Snitzer wrote:
>>> On Mon, May 21 2018 at 10:36am -0400,
>>> Jens Axboe wrote:
>>>
>>>> On 5/21/18 8:31 AM, Mi
On 5/21/18 8:47 AM, Mike Snitzer wrote:
> On Mon, May 21 2018 at 10:36am -0400,
> Jens Axboe wrote:
>
>> On 5/21/18 8:31 AM, Mike Snitzer wrote:
>>> On Mon, May 21 2018 at 10:19am -0400,
>>> Jens Axboe wrote:
>>>
>>>> On 5/21/18 8:03 AM, Mi
On 5/21/18 8:31 AM, Mike Snitzer wrote:
> On Mon, May 21 2018 at 10:19am -0400,
> Jens Axboe wrote:
>
>> On 5/21/18 8:03 AM, Mike Snitzer wrote:
>>> On Sun, May 20 2018 at 6:25pm -0400,
>>> Kent Overstreet wrote:
>>>
>>>> Jens - this
simmer for a bit to give folks a chance
to comment on it.
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
e data structures you've modified in DM.
>
> Could we get the backstory on _why_ you're making this change?
> Would go a long way to helping me appreciate why this is a good use of
> anyone's time.
Yeah, it's in the first series, it gets rid of a pointer
On 1/12/18 2:19 PM, Bart Van Assche wrote:
> On Fri, 2018-01-12 at 14:07 -0700, Jens Axboe wrote:
>> You're really not making it easy for folks to run this :-)
>
> My hope is that the ib_srp and ib_srpt patches will be accepted upstream soon.
> As long as these are not ups
2d/0x90
> io_schedule+0xd/0x30
> generic_file_read_iter+0x32f/0x970
> ? page_cache_tree_insert+0x100/0x100
> __vfs_read+0xcc/0x120
> vfs_read+0x96/0x140
> SyS_read+0x40/0xa0
> do_syscall_64+0x5f/0x1b0
> entry_SYSCALL64_slow_path+0x25/0x25
Do you have the matching blk-mq debugf
details.
Applied for 4.16, and added a patch to silence that false positive
srcu_idx for hctx_unlock() that got reported.
This grows the request a bit, which sucks, but probably unavoidable.
There's some room for improvement with a hole or two, however.
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
ueue_hw_ctx[q->mq_map[cpu]];
that's it. It's just a double index.
So let's put this thing to rest right now - the map call is perfectly
fine, especially since the alternatives are either bloating struct
request or making the code less maintainable.
Foot -> down.
--
Jens Axboe
chronize_rcu();" would be changed into "synchronize_rcu();"
> in
> blk_mq_timeout_work()?
It's a non concern, imho. We do queue mapping all over the place for a variety
of reasons, it's total noise, especially since we're calling [s]rcu anyway
after that.
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
nt_ hctx on completion
> than that one used for submission?
> If not, why can't we just keep a pointer to the hctx in struct request?
Mapping is the right thing to do. We cache the software queue, which
allows us to map back to the same hardware queue. There would be no
point
On 1/8/18 1:15 PM, Jens Axboe wrote:
> On 1/8/18 12:57 PM, Holger Hoffstätte wrote:
>> On 01/08/18 20:15, Tejun Heo wrote:
>>> Currently, blk-mq protects only the issue path with RCU. This patch
>>> puts the completion path under the same RCU protection. This will
tand that this is a somewhat-false positive since the lock always
> precedes the unlock & writes to the value, but can we properly initialize
> or annotate this?
It's not a somewhat false positive, it's a false positive. I haven't seen
that bogus warning with the compiler I
exception is partition remapping for which we'll now need an additional
> partition index. This helps with cases where we submit I/O from a
> character device (nvme or lightnvm passthrough) or a different block
> device (upcoming nvme multipath support).
Added for 4.14, thanks.
-
e it through the block tree, when the md/btrfs
parts are reviewed by the right parties.
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On 07/07/2017 07:51 PM, Goldwyn Rodrigues wrote:
>
>
> On 07/04/2017 05:16 PM, Jens Axboe wrote:
>>
>> Please expedite getting this upstream, asap.
>>
>
> Jens,
>
> I have posted an updated patch [1] and it is acked by David. Would you
> pick it up
gt;
> diff --git a/fs/btrfs/file.c b/fs/btrfs/file.c
> index 59e2dccdf75b..7947781229e5 100644
> --- a/fs/btrfs/file.c
> +++ b/fs/btrfs/file.c
> @@ -1931,6 +1931,7 @@ static ssize_t btrfs_file_write_iter(struct kiocb
> *iocb,
>*/
> update_time_for_write(inode);
>
> +
On 06/28/2017 05:58 AM, Reshetova, Elena wrote:
>
>> Subject: Re: [PATCH 0/5] v3 block subsystem refcounter conversions
>>
>> On Tue, Jun 27, 2017 at 6:26 AM, Jens Axboe wrote:
>>> On 06/27/2017 05:39 AM, Elena Reshetova wrote:
>>>> Changes in v3:
>
at are critical on performance and cannot accept even
> slight delay on the refcounter operations.
Is that true in 4.12-rc, or is that true in a later release once
Linus has pulled those changes in? If the latter, please resend
this when those changes are in, thanks.
--
Jens Axboe
--
To uns
bios to blk_status_t")
>> Signed-off-by: Dan Carpenter
>
> Acked-by: David Sterba
>
> The patch depends on the blk_status_t patchset, so I expect that it's
> going to be merged to that.
Added, thanks.
--
Jens Axboe
--
To unsubscribe from this list: send the li
ux-btrfs last time. If you didn't get them they are available in
> the git tree above. Unfortunately there is no easy way to split them
> up.
Added for 4.13, thanks.
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a m
On Fri, Jun 09 2017, Mike Snitzer wrote:
> On Thu, Jun 08 2017 at 11:42am -0400,
> Jens Axboe wrote:
>
> > On 06/03/2017 01:37 AM, Christoph Hellwig wrote:
> > > This series introduces a new blk_status_t error code type for the block
> > > layer so that we can
ux-btrfs last time. If you didn't get them they are available in
> the git tree above. Unfortunately there is no easy way to split them
> up.
Mike, can you take a look at the dm bits in this series? I'd like to get
this queued up, but I'd also greatly prefer if the dm pat
IT, this looks like a somewhat stale comment.
This patch should be prefixed with 'block', not 'fs'.
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
K_MAY_BLOCK_REQS and use it for devices which do wait such as md/dm.
> Is that what you are hinting at? Or do you have something else in mind?
You are misunderstanding. What Christoph (correctly) says is that request
based drivers do not block, so all of those are fine. What you need to
worry about is
On 04/21/2017 09:22 AM, Peter Zijlstra wrote:
> On Fri, Apr 21, 2017 at 08:03:13AM -0600, Jens Axboe wrote:
>> You have it so easy - the code is completely standalone, building a
>> small test framework around it and measuring performance in _user space_
>> is trivial.
>
&
unt_t compares to atomic_t
for various (valid) use cases.
Once you have that, convincing people to adopt it would be so much
easier. So stop talking about excuses, and start producing some numbers.
If you can't do that, my level of interest in converting anything in
block is zero.
--
k/linux-fs.git bdi
>
> Since all patches got reviewed by Christoph, can you please pick them up Jens?
> Thanks!
Yep, picked up for 4.12. Thanks Jan!
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On 03/24/2017 05:32 AM, Goldwyn Rodrigues wrote:
>
>
> On 03/16/2017 09:33 AM, Jens Axboe wrote:
>> On 03/15/2017 03:51 PM, Goldwyn Rodrigues wrote:
>>> diff --git a/block/blk-core.c b/block/blk-core.c
>>> index 0eeb99e..2e5cba2 100644
>>> --- a/b
bio_flagged(bio, BIO_NOWAIT))
> + bio_wouldblock_error(bio);
> return BLK_QC_T_NONE;
> }
>
This seems a little fragile now, since not both paths free the bio.
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
atchwork.kernel.org/patch/9571051/
are not blk-mq, but writeback throttling, and drivers that explicitly
hook into ->make_request_fn.
As others have mentioned, it's a total non-starter to focus on the
deprecated IO path and just ignore the new one. Back to the drawing
board.
-
On 03/06/2017 11:17 AM, Avi Kivity wrote:
>
>
> On 03/06/2017 07:06 PM, Jens Axboe wrote:
>> On 03/06/2017 09:59 AM, Avi Kivity wrote:
>>>
>>> On 03/06/2017 06:08 PM, Jens Axboe wrote:
>>>> On 03/06/2017 08:59 AM, Avi Kivity wrote:
>>>>&g
On 03/06/2017 09:59 AM, Avi Kivity wrote:
>
>
> On 03/06/2017 06:08 PM, Jens Axboe wrote:
>> On 03/06/2017 08:59 AM, Avi Kivity wrote:
>>> On 03/06/2017 05:38 PM, Jens Axboe wrote:
>>>> On 03/06/2017 08:29 AM, Avi Kivity wrote:
>>>>> On 03/06/20
On 03/06/2017 08:59 AM, Avi Kivity wrote:
> On 03/06/2017 05:38 PM, Jens Axboe wrote:
>> On 03/06/2017 08:29 AM, Avi Kivity wrote:
>>>
>>> On 03/06/2017 05:19 PM, Jens Axboe wrote:
>>>> On 03/06/2017 01:25 AM, Jan Kara wrote:
>>>>> On Sun 05
On 03/06/2017 08:29 AM, Avi Kivity wrote:
>
>
> On 03/06/2017 05:19 PM, Jens Axboe wrote:
>> On 03/06/2017 01:25 AM, Jan Kara wrote:
>>> On Sun 05-03-17 16:56:21, Avi Kivity wrote:
>>>>> The goal of the patch series is to return -EAGAIN/-EWOULDBLOCK if
>
potentially create millions of
pending work items (and IOs). That's why the current API is safe, even
though it does suck that it block seemingly randomly for users.
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On 02/20/2017 08:41 AM, James Bottomley wrote:
> On Mon, 2017-02-20 at 08:15 -0700, Jens Axboe wrote:
>> On 02/20/2017 04:16 AM, Elena Reshetova wrote:
>>> Now when new refcount_t type and API are finally merged
>>> (see include/linux/refcount.h), the following
here is
it merged? Don't send code like this without the necessary
infrastructure being in mainline.
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
hing to discuss.
I'd be interested in joining that session too, for obvious reasons.
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
d I'd like to have the fix
in at least a day before that..
Just committed half an hour ago with the acks etc, I'll send it to you
shortly.
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kerne
splat during boot for me too.
Now the fun part, let's see if it fixed the 'weird shit' that Trinity
was stumbling on.
Let's let the testing simmer overnight, then I'll turn this into a real
patch tomorrow and get it submitted.
--
Jens Axboe
--
To unsubscribe from this lis
On 10/26/2016 05:19 PM, Chris Mason wrote:
On Wed, Oct 26, 2016 at 05:03:45PM -0600, Jens Axboe wrote:
On 10/26/2016 04:58 PM, Linus Torvalds wrote:
On Wed, Oct 26, 2016 at 3:51 PM, Linus Torvalds
wrote:
Dave: it might be a good idea to split that "WARN_ON_ONCE()" in
blk_mq_merg
On 10/26/2016 05:08 PM, Linus Torvalds wrote:
On Wed, Oct 26, 2016 at 4:03 PM, Jens Axboe wrote:
Actually, I think I see what might trigger it. You are on nvme, iirc,
and that has a deep queue.
Yes. I have long since moved on from slow disks, so all my systems are
not just flash, but m.2
lags);
- hctx->queued++;
- data->hctx = hctx;
- data->ctx = ctx;
+ data->hctx->queued++;
return rq;
}
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
ata->ctx = ctx;
+ data->hctx->queued++;
return rq;
}
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
ing to add a call to
blk_rq_dump_flags() as well, in case this is some special request.
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
o *bio)
return cookie;
}
- if (!blk_mq_merge_queue_io(data.hctx, data.ctx, rq, bio)) {
+ if (!blk_mq_merge_queue_io(data.hctx, rq, bio)) {
/*
* For a SYNC request, send it to the hardware immediately. For
On 10/18/2016 05:31 PM, Chris Mason wrote:
On Tue, Oct 18, 2016 at 05:12:41PM -0600, Jens Axboe wrote:
On 10/18/2016 04:42 PM, Dave Jones wrote:
So Chris had me do a run on ext4 just for giggles. It took a while, but
eventually this fell out...
WARNING: CPU: 3 PID: 21324 at lib/list_debug.c
.
This sometimes reproduces within minutes, sometimes hours, which makes
it a pain to bisect. It only started showing up this merge window though.
Chinner reported the same thing on XFS, I'll look into it asap.
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
ce this patch series. Please consider these patches for inclusion in
the upstream Linux kernel.
Thanks Bart, I like this series. Applied for 4.9.
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.or
On 08/02/2016 05:32 AM, Christoph Hellwig wrote:
On Mon, Aug 01, 2016 at 01:55:36PM -0600, Jens Axboe wrote:
Set of three patches, where the target one is an actual bug fix...
Temporary branch, I'll rebase it once -rc1 is out, if more
changes/fixups need to be made in the next week until
On 08/01/2016 09:17 AM, Jens Axboe wrote:
On 08/01/2016 05:47 AM, Christoph Hellwig wrote:
On Sat, Jul 30, 2016 at 04:45:48PM -0500, Shaun Tancheff wrote:
bi_rw should be using bio_set_op_attrs to set bi_rw.
Looks fine,
Reviewed-by: Christoph Hellwig
Added, thanks Shaun.
Jens,
what do
get build
breakage, than potentially much worse breakage.
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On 07/15/2016 09:03 AM, Vincent Stehlé wrote:
Add missing comparison to op in expression, which was forgotten when doing
the REQ_OP transition.
Thanks, added to the 4.8 branch.
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a
fast path, single device, we don't have an issue. Yet
this patch slows down that part unnecessarily.
Fix this for the fat dm/md stacks, and don't add unwarranted fat in the
normal fast path. The dm/md stacks won't notice a bit of extra overhead,
whereas the core path is prett
On 11/20/2015 08:14 PM, Liu Bo wrote:
On Fri, Nov 20, 2015 at 07:26:45PM -0700, Jens Axboe wrote:
On 11/20/2015 04:08 PM, Liu Bo wrote:
On Fri, Nov 20, 2015 at 02:30:43PM -0700, Jens Axboe wrote:
On 11/20/2015 06:13 AM, Chris Mason wrote:
On Thu, Nov 19, 2015 at 05:49:37PM -0800, Liu Bo
On 11/20/2015 04:08 PM, Liu Bo wrote:
On Fri, Nov 20, 2015 at 02:30:43PM -0700, Jens Axboe wrote:
On 11/20/2015 06:13 AM, Chris Mason wrote:
On Thu, Nov 19, 2015 at 05:49:37PM -0800, Liu Bo wrote:
while xfstesting, this bug[1] is spotted by both btrfs/061 and btrfs/063,
so those sub-stripe
request before flush, that might destroy merging opportunities. I'll
unify the mq/sq parts.
--
Jens Axboe
diff --git a/block/blk-mq.c b/block/blk-mq.c
index 3ae09de62f19..0325dcec8c74 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -1380,12 +1391,15 @@ static blk_qc_t blk_sq_make_reques
On 07/28/2015 05:12 AM, Christoph Hellwig wrote:
On Fri, Jul 24, 2015 at 10:36:45AM -0600, Jens Axboe wrote:
Right, I don't think we need to do that though. If you look at the flags
usage, it's all over the map. Some use test/set_bit, some set it just by
OR'ing the mask. There
On 07/24/2015 04:49 AM, Christoph Hellwig wrote:
On Wed, Jul 22, 2015 at 03:59:46PM -0600, Jens Axboe wrote:
One possible solution would be to shrink bi_flags to an unsigned int, no
problems fitting that in. Then we could stuff bi_error in that (new) hole,
and we would end up having the same
On 07/22/2015 12:51 PM, Jens Axboe wrote:
On 07/20/2015 07:29 AM, Christoph Hellwig wrote:
Currently we have two different ways to signal an I/O error on a BIO:
(1) by clearing the BIO_UPTODATE flag
(2) by returning a Linux errno value to the bi_end_io callback
The first one has the
this is a good change, the only part I _really_ dislike is that
this now bumps a struct bio from 2 cache lines to 3. Have you done any
perf testing?
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kerne
or since forever, actually) is that this is
one single 4kb page. If you go higher, that would require a higher order
allocation. Not impossible, but it's definitely a potential issue. It's
a lot saner to string bios at that point, with separate 0 order allocs.
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On 2014-06-18 00:21, Konstantinos Skarlatos wrote:
On 18/6/2014 5:11 πμ, Jens Axboe wrote:
On 2014-06-17 14:35, Konstantinos Skarlatos wrote:
Hi all,
with 3.16-rc1 rsync stops writing to my btrfs filesystem and stays at a
D+ state.
git bisect showed that the problematic commit is
762380ad9322951cea4ce9d24864265f9c66a916
Author: Jens Axboe
Date: Thu Jun 5 13:38:39 2014 -0600
block: add notion of a chunk size for request merging
Some drivers have different limits on what size a request should
optimally be, depending on the offset of the request. Similar to
dividing a device into
_remaining when we restore the orig bio as well.
>>
>> Reported-and-Tested-by: Fengguang wu
>> CC: Kent Overstreet
>> CC: Jens Axboe
>> CC: Chris Mason
>> Signed-off-by: Muthukumar Ratty
>>
>
> Reviewed-by: Chris Mason
>
> Jens, please pull
On Sat, Nov 23 2013, Kent Overstreet wrote:
> It was being open coded in a few places.
Thanks, applied (with Neils ack).
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo
...
> mirror = (int)(unsigned long)bio->bi_bdev;
> ...
> }
>
> Ewweehh
>
> No wonder this thing crashes. Chris, can't the original bio carry
> bbio in bi_private and let end_bio_extent_readpage() free the bbio
> i
okay without the new TP.
The tracing commit was already backed out yesterday, so no problems
there. I figured it'd be a bit too late to fix something this nasty in a
suitably clean and straight forward fashion.
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe
s in v2: update commit log, btrfs_abort_devices() was removed
> already.
Thanks Asias, applied.
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On 2010-09-23 22:53, Greg KH wrote:
> On Thu, Sep 23, 2010 at 09:40:14PM +0200, Jens Axboe wrote:
>> On 2010-09-23 21:38, Andrew Morton wrote:
>>>
>>> (Cc sta...@kernel.org)
>>>
>>> On Wed, 22 Sep 2010 21:54:30 -0300
>>> Cesar Eduardo Ba
into -stable until this
> regression is sorted out!
It was just added, I'm discussing this with Chris on irc as I type this.
But yes, lets not replace a regression with a new regression :-). So
Greg, please hold off on these for a little while.
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
L
without wrapping it in a function.
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On 08/08/2010 03:18 AM, Andi Kleen wrote:
> Jens Axboe writes:
>>
>> Also, I didn't see Chris mention this, but if you have a newer intel box
>> you can use hw accellerated crc32c instead. For some reason my test box
>> always loads crc32c and not crc32c-inte
On 2010-08-05 16:51, Chris Mason wrote:
> And then we need to setup a fio job file that hammers on all the ssds at
> once. I'd have it use adio/dio and talk directly to the drives. I'd do
> something like this for the fio job file, but Jens Axboe is cc'd and he
> might
on the notification if we ever add other callers to
>wait for it.
> - make earlier completion notification depending on the on-stack
>allocation, not the sync mode. If we introduce new callers that
>want to do WB_SYNC_NONE writeback from on-stack callers this
On Fri, Mar 19 2010, Shaohua Li wrote:
> On Fri, Mar 19, 2010 at 04:22:11PM +0800, Jens Axboe wrote:
> > On Fri, Mar 19 2010, Shaohua Li wrote:
> > > On Fri, Mar 19, 2010 at 08:59:48AM +0800, Shaohua Li wrote:
> > > > On Thu, Mar 18, 2010 at 08:53:13PM +0800, Chris
ox with hardware
> > > crc32c enabled?
> > yes, this machine supports sse4.2 instruction. Let me check the result with
> > checksum
> > disabled.
> Sounds no big difference with checksum disabled. I format the disks and redo
> the test:
> 128k ra: 539648 k/s
>
On Mon, Feb 08 2010, Jens Axboe wrote:
> Cache stats (millions)
>
> Kernel References Misses
> --
> baseline35472387
> patched 38222351
>
> These numb
have been a bit flukey (one fast run, should probably be
excluded).
Let me know if you want more tests.
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
d the same thing on a reiserfs partition on the same
> system, worked fine.
Looks like that iscsi target relies on having fops->aio_write() there,
which btrfs doesn't have. It's a bug in the iscsi driver.
--
Jens Axboe
--
To unsubscribe from this list: send the line "u
work fine on that setup. In fact, barriers were first
implemented for PATA back in the day :-)
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Sep 17 2009, Markus Trippelsdorf wrote:
> On Thu, Sep 17, 2009 at 08:44:56AM +0200, Jens Axboe wrote:
> > On Thu, Sep 17 2009, Markus Trippelsdorf wrote:
> > > On Tue, Sep 08, 2009 at 10:00:42PM +0200, Jens Axboe wrote:
> > > > On Mon, Sep 07 2009, Markus Trip
On Thu, Sep 17 2009, Markus Trippelsdorf wrote:
> On Tue, Sep 08, 2009 at 10:00:42PM +0200, Jens Axboe wrote:
> > On Mon, Sep 07 2009, Markus Trippelsdorf wrote:
> > > Just got this error today in my dmesg:
> > > btrfs csum failed ino 1483065 off 158482432 csum 4283543
1 - 100 of 128 matches
Mail list logo
