On 5/21/18 10:09 AM, Mike Snitzer wrote:
> On Mon, May 21 2018 at 11:36am -0400,
> Jens Axboe <ax...@kernel.dk> wrote:
>
>> On 5/21/18 9:18 AM, Mike Snitzer wrote:
>>> On Mon, May 21 2018 at 11:09am -0400,
>>> Jens Axboe <ax...@kernel.dk> wrote:
&g
On 5/21/18 9:18 AM, Mike Snitzer wrote:
> On Mon, May 21 2018 at 11:09am -0400,
> Jens Axboe <ax...@kernel.dk> wrote:
>
>> On 5/21/18 9:04 AM, Mike Snitzer wrote:
>>> On Mon, May 21 2018 at 10:52am -0400,
>>> Jens Axboe <ax...@kernel.dk> wrote:
&g
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 <kent.overstr...@gmail.com> wrote:
>>
On 5/21/18 9:04 AM, Mike Snitzer wrote:
> On Mon, May 21 2018 at 10:52am -0400,
> Jens Axboe <ax...@kernel.dk> wrote:
>
>> On 5/21/18 8:47 AM, Mike Snitzer wrote:
>>> On Mon, May 21 2018 at 10:36am -0400,
>>> Jens Axboe <ax...@kernel.dk> wrote:
&g
On 5/21/18 8:47 AM, Mike Snitzer wrote:
> On Mon, May 21 2018 at 10:36am -0400,
> Jens Axboe <ax...@kernel.dk> wrote:
>
>> On 5/21/18 8:31 AM, Mike Snitzer wrote:
>>> On Mon, May 21 2018 at 10:19am -0400,
>>> Jens Axboe <ax...@kernel.dk> wrote:
&g
On 5/21/18 8:31 AM, Mike Snitzer wrote:
> On Mon, May 21 2018 at 10:19am -0400,
> Jens Axboe <ax...@kernel.dk> wrote:
>
>> On 5/21/18 8:03 AM, Mike Snitzer wrote:
>>> On Sun, May 20 2018 at 6:25pm -0400,
>>> Kent Overstreet <kent.overstr...@gmail.co
immer 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
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 indirection.
--
Jens Axboe
--
To unsu
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 upstream
_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 debugfs output for
ied 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
at'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
--
To unsubscribe from this list: send the line "
h a _different_ 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 in
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
I understand 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'm running
ption 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.
--
Jens Ax
hrough 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
ode);
>
> + pos = iocb->ki_pos;
> start_pos = round_down(pos, fs_info->sectorsize);
> oldsize = i_size_read(inode);
> if (start_pos > oldsize) {
Please expedite getting this upstream, 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
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 <ax...@kernel.dk> wrote:
>>> On 06/27/2017 05:39 AM, Elena Reshetova wrote:
>>&g
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
--
T
bios to blk_status_t")
>> Signed-off-by: Dan Carpenter <dan.carpen...@oracle.com>
>
> Acked-by: David Sterba <dste...@suse.com>
>
> The patch depends on the blk_status_t patchset, so I expect that it's
> going to be merged to that.
Added, thanks.
--
Jens Axb
linux-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 message to
On Fri, Jun 09 2017, Mike Snitzer wrote:
> On Thu, Jun 08 2017 at 11:42am -0400,
> Jens Axboe <ax...@kernel.dk> 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
> >
linux-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 patches had sign
of
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
lag to
> BLK_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 yo
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.
>
&
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.
--
Jens Axboe
--
To unsubscribe fro
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_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
ork.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.
--
Jens Axboe
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
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 i
ate 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
ere 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
ested 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
t 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 list: send the line "unsubsc
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
<torva...@linux-foundation.org> wrote:
Dave: it might be a good idea to
On 10/26/2016 05:08 PM, Linus Torvalds wrote:
On Wed, Oct 26, 2016 at 4:03 PM, Jens Axboe <ax...@fb.com> 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
no
+;
- 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
->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
l 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
rn 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
* an ASYNC request, just ensure that w
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
is 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 <h...@lst.de>
Added, thanks
better to 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
, 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 pretty well optimized.
--
Jens Axboe
, 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_request(struct request_queue *q
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
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's no reason we
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
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.kernel.org
More
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
762380ad9322951cea4ce9d24864265f9c66a916
Author: Jens Axboe ax...@fb.com
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
fengguang...@intel.com
CC: Kent Overstreet k...@daterainc.com
CC: Jens Axboe ax...@kernel.dk
CC: Chris Mason c...@fb.com
Signed-off-by: Muthukumar Ratty mut...@gmail.com
Reviewed-by: Chris Mason c...@fb.com
Jens, please pull this one in.
Done, with the added reviewed and tested-by's.
--
Jens
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 info at http
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 linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo
;
...
}
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
instead of abusing bi_bdev like this?
Ugh, wtf.
Chris, time for a swim in the bay :-)
--
Jens Axboe
--
To unsubscribe from this list: send
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 Barros ces...@cesarb.net wrote:
This started appearing for me on v2.6.36-rc5-49
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
.
--
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 ax...@kernel.dk 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-intel, so I need to do that manually
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 make another suggestion
commit would potentially pass in stack cruft as
the wbc arg. So I think we can safely consider it fixed now.
--
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
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 Mason wrote:
On Thu, Mar 18, 2010
should be included. Cache misses are
provably down and the patch makes a lot of sense just logically. The
patched runs seemed more stable, and my gut tells me that the unpatched
runs may have been a bit flukey (one fast run, should probably be
excluded).
Let me know if you want more tests.
--
Jens
. 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 Trippelsdorf wrote:
Just got this error
on single threaded. Seems
unable to keep IO outstanding to the device. Less that 60% busy on
the DM device, compared to 97%+ for all other filesystems.
nodatacow helps out, increasing utilization to about 70%, but still
trails by a large margin.
Hi Steve,
Jens Axboe did some
On Wed, Sep 09 2009, Markus Trippelsdorf wrote:
On Wed, Sep 09, 2009 at 09:01:41AM +0200, Jens Axboe wrote:
On Wed, Sep 09 2009, Markus Trippelsdorf wrote:
On Tue, Sep 08, 2009 at 10:32:14PM +0200, Jens Axboe wrote:
On Tue, Sep 08 2009, Markus Trippelsdorf wrote:
On Tue, Sep 08
On Wed, Sep 09 2009, Daniel J Blueman wrote:
On Wed, Sep 9, 2009 at 8:01 AM, Jens Axboejens.ax...@oracle.com wrote:
On Wed, Sep 09 2009, Markus Trippelsdorf wrote:
On Tue, Sep 08, 2009 at 10:32:14PM +0200, Jens Axboe wrote:
On Tue, Sep 08 2009, Markus Trippelsdorf wrote:
On Tue, Sep 08
On Tue, Sep 08 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 4283543305 private
43905798
linux
of data looks like (and how big it is)?
--
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 Fri, Aug 21 2009, Yan, Zheng wrote:
2009/8/21 Jens Axboe jens.ax...@oracle.com:
On Fri, Aug 21 2009, Yan, Zheng wrote:
2009/8/21 Jens Axboe jens.ax...@oracle.com:
On Thu, Aug 20 2009, Yan, Zheng wrote:
2009/8/20 Nick Piggin npig...@suse.de:
On Wed, Aug 19, 2009 at 10:59:07AM
);
rb_erase(BTRFS_I(inode)-rb_node, root-inode_tree);
- spin_unlock(root-inode_lock);
RB_CLEAR_NODE(BTRFS_I(inode)-rb_node);
}
+ spin_unlock(root-inode_lock);
}
static noinline void init_btrfs_i(struct inode *inode)
--
Jens Axboe
On Thu, Aug 20 2009, Yan, Zheng wrote:
2009/8/20 Nick Piggin npig...@suse.de:
On Wed, Aug 19, 2009 at 10:59:07AM +0200, Jens Axboe wrote:
On Wed, Aug 19 2009, Nick Piggin wrote:
On Wed, Aug 19, 2009 at 10:46:59AM +0200, Jens Axboe wrote:
On Wed, Aug 19 2009, Nick Piggin wrote
On Wed, Aug 19 2009, Nick Piggin wrote:
On Tue, Aug 18, 2009 at 11:19:10PM +0200, Jens Axboe wrote:
On Wed, Aug 19 2009, Yan, Zheng wrote:
2009/8/19 Nick Piggin npig...@suse.de:
Hi,
Ran into a problem stress testing my btrfs truncate conversion
attempt...
Unfortunately
On Wed, Aug 19 2009, Nick Piggin wrote:
On Wed, Aug 19, 2009 at 10:46:59AM +0200, Jens Axboe wrote:
On Wed, Aug 19 2009, Nick Piggin wrote:
See my other reply. It *can* work with key aliases, but this particular
code does not.
It is pretty easy obviously to put in duplicates
no idea how can it happen.
It can work with key aliases, if it's a problem then it's likely due to
another problem in related lookup code.
--
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
that device.
When there are several, it should do something different.
I actually think it's quite sane, since then you get the same behaviour
on multi vs single disk file systems. The last thing you want is to have
different behaviour when you later add a disk, for instance.
--
Jens Axboe
it, and use /dev/sda4 to mount the filesystem:
# umount /dev/sdb4
# mount /dev/sda4 /mnt/btrfs/
Try btrfsctl -a first.
--
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
On Fri, Aug 07 2009, Yan Zheng wrote:
On 08/07/2009 02:50 PM, Jens Axboe wrote:
On Fri, Aug 07 2009, Yan Zheng wrote:
invalidate_inode_pages2_range may return -EBUSY occasionally
which results Oops. This patch fixes the issue by moving
invalidate_inode_pages2_range into a loop and keeping
there.
--
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
to. But just running tests on
the drive does show that it performs well for most things.
--
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
);
em = lookup_extent_mapping(em_tree, logical, *length);
Careful, some archs require a barrier there. It's dangerous to makes
assumptions about the underlying implementation of such things, I'd
leave that one alone.
--
Jens Axboe
--
To unsubscribe from this list: send the line unsubscribe
On Wed, Jul 30 2008, Chris Mason wrote:
On Wed, 2008-07-30 at 21:56 +0200, Jens Axboe wrote:
On Wed, Jul 30 2008, Sven Wegener wrote:
Add a couple of #if's to follow API changes.
Signed-off-by: Sven Wegener [EMAIL PROTECTED]
---
extent_io.c | 16
file.c
97 matches
Mail list logo
