On Tue, Aug 01, 2023 at 06:37:02PM +0530, Nitesh Shetty wrote:
> On 23/07/20 09:50AM, Christoph Hellwig wrote:
> > > +static void *blkdev_copy_alloc_buf(sector_t req_size, sector_t
> > > *alloc_size,
> > > + gfp_t gfp_mask)
> > > +{
> > > + int min_size = PAGE_SIZE;
> > > + void *buf;
> >
On Fri, Jun 09, 2023 at 10:57:27PM +0200, Mikulas Patocka wrote:
>
>
> On Tue, 30 May 2023, Kent Overstreet wrote:
>
> > On Tue, May 30, 2023 at 05:00:39PM -0400, Mikulas Patocka wrote:
> > > I'd like to know how do you want to do coverage analysis? By
> &
On Tue, May 30, 2023 at 08:15:41AM -0400, Mikulas Patocka wrote:
>
>
> On Mon, 29 May 2023, Mikulas Patocka wrote:
>
> > The oops happens in set_btree_iter_dontneed and it is caused by the fact
> > that iter->path is NULL. The code in try_alloc_bucket is buggy because it
> > sets "struct btree
On Tue, May 30, 2023 at 05:00:39PM -0400, Mikulas Patocka wrote:
> I'd like to know how do you want to do coverage analysis? By instrumenting
> each branch and creating a test case that tests that the branch goes both
> ways?
Documentation/dev-tools/gcov.rst. The compiler instruments each branch
On Tue, May 30, 2023 at 09:12:44AM +1000, Dave Chinner wrote:
> Perhaps it is worthwhile running the same tests on btrfs so we can
> something to compare the bcachefs behaviour to. I suspect that btrfs
> will fair little better on the single device, no checksums
> corruption test
It's also a t
On Mon, May 29, 2023 at 04:59:40PM -0400, Mikulas Patocka wrote:
> Hi
>
> I improved the dm-flakey device mapper target, so that it can do random
> corruption of read and write bios - I uploaded it here:
> https://people.redhat.com/~mpatocka/testcases/bcachefs/dm-flakey.c
>
> I set up dm-flakey
On Fri, Jul 01, 2022 at 11:58:35AM +0800, Ming Lei wrote:
> Why do we need to pay the cost(4 bytes added to bio and the updating
> in absolutely fast path) if rewind isn't used? So far, only dm requeue
> needs it, and it is one very unusual event.
>
> Assuming fixed bio end sector should cover mos
On Wed, Jun 29, 2022 at 11:16:10AM -0600, Jens Axboe wrote:
> Not sure what Christoph change you are referring to, but all the ones
> that I did to improve the init side were all backed by numbers I ran at
> that time (and most/all of the commit messages will have that data). So
> yes, it is indeed
On Wed, Jun 29, 2022 at 01:00:52PM -0600, Jens Axboe wrote:
> On 6/29/22 12:40 PM, Kent Overstreet wrote:
> > On Wed, Jun 29, 2022 at 11:16:10AM -0600, Jens Axboe wrote:
> >> Not sure what Christoph change you are referring to, but all the ones
> >> that I did to imp
On Wed, Jun 29, 2022 at 12:37:59PM -0700, Bart Van Assche wrote:
> On 6/29/22 12:05, Kent Overstreet wrote:
> > On Wed, Jun 29, 2022 at 11:51:27AM -0700, Bart Van Assche wrote:
> > > On 6/29/22 11:40, Kent Overstreet wrote:
> > > > But Jens, to be blunt - I know we ha
On Wed, Jun 29, 2022 at 11:51:27AM -0700, Bart Van Assche wrote:
> On 6/29/22 11:40, Kent Overstreet wrote:
> > But Jens, to be blunt - I know we have different priorities in the way we
> > write code.
>
> Please stay professional in your communication and focus on the techn
io_rewind() patch - what do you think of this?
-- >8 --
From: Kent Overstreet
Subject: [PATCH] block: add bio_(get|set)_pos()
Commit 7759eb23fd98 ("block: remove bio_rewind_iter()") removes
the similar API because the following reasons:
```
It is pointed that bio_rewind_iter()
On Wed, Jun 29, 2022 at 02:07:08AM -0400, Mike Snitzer wrote:
> Please try to dial down the hyperbole and judgment. Ming wrote this
> code. And you haven't been able to point out anything _actually_ wrong
> with it (yet).
>
> This patch's header does need editing for clarity, but we can help
> imp
On Thu, Jun 30, 2022 at 08:47:13AM +0800, Ming Lei wrote:
> What is the difference between bio_set_pos and bio_rewind()? Both have
> to restore bio->bi_iter(the sector part and the bvec part).
>
> Also how to update ->bi_done which 'counts bytes advanced'? You meant doing
> it in
> very bio_advan
On Wed, Jun 29, 2022 at 12:37:59PM -0700, Bart Van Assche wrote:
> On 6/29/22 12:05, Kent Overstreet wrote:
> > On Wed, Jun 29, 2022 at 11:51:27AM -0700, Bart Van Assche wrote:
> > > On 6/29/22 11:40, Kent Overstreet wrote:
> > > > But Jens, to be blunt - I know we ha
On Tue, Jun 28, 2022 at 01:41:12PM -0400, Mike Snitzer wrote:
> On Tue, Jun 28 2022 at 12:36P -0400,
> Kent Overstreet wrote:
>
> > On Tue, Jun 28, 2022 at 03:49:28PM +0800, Ming Lei wrote:
> > > On Tue, Jun 28, 2022 at 12:26:10AM -0400, Kent Overstreet wrote:
> >
On Tue, Jun 28, 2022 at 03:49:28PM +0800, Ming Lei wrote:
> On Tue, Jun 28, 2022 at 12:26:10AM -0400, Kent Overstreet wrote:
> > On Mon, Jun 27, 2022 at 03:36:22PM +0800, Ming Lei wrote:
> > > Not mention bio_iter, bvec_iter has been 32 bytes, which is too big to
> &g
On Tue, Jun 28, 2022 at 12:13:06PM -0600, Jens Axboe wrote:
> It's much less about using whatever amount of memory for inflight IO,
> and much more about not bloating fast path structures (of which the bio
> is certainly one). All of this gunk has to be initialized for each IO,
> and that's the rea
On Tue, Jun 28, 2022 at 03:42:52PM +0800, Ming Lei wrote:
> I don't see there is 'queue depth' for bio or bio driver.
>
> 32 bytes have been big, and memory footprint is increased too since the data
> has been
> prepared for the future possible rewind. If crypt or integrity is considered,
> it
>
On Fri, Jun 24, 2022 at 10:12:52PM +0800, Ming Lei wrote:
> Commit 7759eb23fd98 ("block: remove bio_rewind_iter()") removes
> the similar API because the following reasons:
>
> ```
> It is pointed that bio_rewind_iter() is one very bad API[1]:
>
> 1) bio size may not be restored after
On Mon, Jun 27, 2022 at 03:36:22PM +0800, Ming Lei wrote:
> On Sun, Jun 26, 2022 at 04:14:58PM -0400, Kent Overstreet wrote:
> > On Fri, Jun 24, 2022 at 10:12:52PM +0800, Ming Lei wrote:
> > > Commit 7759eb23fd98 ("block: remove bio_rewind_iter()") removes
>
On Mon, Jun 27, 2022 at 03:36:22PM +0800, Ming Lei wrote:
> Not mention bio_iter, bvec_iter has been 32 bytes, which is too big to
> hold in per-io data structure. With this patch, 8bytes is enough
> to rewind one bio if the end sector is fixed.
And with rewind, you're making an assumption about t
sted and confirmed and mailed out the patch below, you want to double
check for me?
commit 1678b1f8d46c9f8f52372edfde7b9a94e9b416fe
Author: Kent Overstreet
Date: Tue Jun 5 05:05:51 2018 -0400
dm: Use kzalloc for all structs with embedded biosets/mempools
mempool_init()/bioset_i
On Tue, Jun 05, 2018 at 04:08:37PM +0800, Ming Lei wrote:
> Hi,
>
> The following failure is triggered when running xfstests(ext4)
> generic/081 with the linus tree(4.17.0_716a685fdb89).
>
> It might be related with recent mempool change.
Oh _fuck_, I forgot to check that the structs the mempool
The counter for the number of allocated pages includes pages in the
mempool's reserve, so checking that the number of allocated pages is 0
needs to happen after we exit the mempool.
Signed-off-by: Kent Overstreet
---
drivers/md/dm-crypt.c | 8
1 file changed, 4 insertions(
[] (do_vfs_ioctl) from []
> (ksys_ioctl+0x34/0x5c)
> [ 150.455994] [] (ksys_ioctl) from []
> (ret_fast_syscall+0x0/0x28)
>
> ---
>
> Full log is here:
> https://krzk.eu/#/builders/1/builds/2117/steps/18/logs/serial0
>
> Bisect could not work reliably because a
On Fri, Jun 01, 2018 at 06:50:13PM -0600, Jens Axboe wrote:
> Nevermind that for now, do you have a fix for the issue reported?
Yeah, but let me look over it again tomorrow when I'm sober before I send it out
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-
On Wed, Feb 08, 2017 at 11:34:07AM -0500, Mike Snitzer wrote:
> On Tue, Feb 07 2017 at 11:58pm -0500,
> Kent Overstreet wrote:
>
> > On Tue, Feb 07, 2017 at 09:39:11PM +0100, Pavel Machek wrote:
> > > On Mon 2017-02-06 17:49:06, Kent Overstreet wrote:
> > > >
On Tue, Feb 07, 2017 at 09:39:11PM +0100, Pavel Machek wrote:
> On Mon 2017-02-06 17:49:06, Kent Overstreet wrote:
> > On Mon, Feb 06, 2017 at 04:47:24PM -0900, Kent Overstreet wrote:
> > > On Mon, Feb 06, 2017 at 01:53:09PM +0100, Pavel Machek wrote:
> > > > Stil
; > > > ...and still there in 4.5-rc4 :-(.
> > >
> > > You're directing this concern to the wrong person.
> > >
> > > I already told you DM is _not_ contributing any extra "bioset" threads
> > > (ever since commit dbba42d8a).
> >
> > Well, sorry about that.
On Mon, Feb 06, 2017 at 04:47:24PM -0900, Kent Overstreet wrote:
> On Mon, Feb 06, 2017 at 01:53:09PM +0100, Pavel Machek wrote:
> > Still there on v4.9, 36 threads on nokia n900 cellphone.
> >
> > So.. what needs to be done there?
> But, I just got an idea for how to h
On Sun, Dec 18, 2016 at 06:17:55PM -0500, Mike Snitzer wrote:
> Spinning it as a pure bugfix is a reach (as Eric's header documents the
> patch, the case is weak for cc'ing stable). Reality is the change is
> needed to enable a new bcache feature. I'm not going to rush
> feature-enabling change t
On Sat, Dec 17, 2016 at 10:58:00AM -0500, Mike Snitzer wrote:
> The time for 4.10 inclusion has passed. This needs to wait until 4.11.
>
> It also needs more review, testing and possible re-working. Each DM
> target shouldn't have to worry about these details (though I do grant
> that dm-crypt.c
On Mon, Oct 31, 2016 at 08:29:01AM -0700, Christoph Hellwig wrote:
> On Sat, Oct 29, 2016 at 04:08:08PM +0800, Ming Lei wrote:
> > Avoid to access .bi_vcnt directly, because it may be not what
> > the driver expected any more after supporting multipage bvec.
> >
> > Signed-off-by: Ming Lei
>
> I
On Wed, Jul 27, 2016 at 05:16:36PM +0200, Stefan Bader wrote:
> So here is another attempt which does half the proposed changes. And before
> you
> point out that it looks still ugly, let me explain some reasons. The goal for
> me
> would be to have something as small as possible to be acceptable
On Tue, Jul 26, 2016 at 11:51:25AM +0200, Stefan Bader wrote:
> On 21.07.2016 10:58, Stefan Bader wrote:
> > I was pointed at the thread which seems to address the same after
> > I wrote most of below text. Did not want to re-write this so please
> > bear with the odd layout.
> >
> > https://www.r
On Tue, Jul 26, 2016 at 02:32:31PM +0200, Stefan Bader wrote:
> On 26.07.2016 12:21, Kent Overstreet wrote:
> > On Tue, Jul 26, 2016 at 11:51:25AM +0200, Stefan Bader wrote:
> >> On 21.07.2016 10:58, Stefan Bader wrote:
> >>> I was pointed at the thread which s
On Wed, Jun 01, 2016 at 11:05:20AM -0700, Eric Wheeler wrote:
> On Wed, 1 Jun 2016, Zhengyuan Liu wrote:
>
> > Hi, I have created a mapped block device (bcach0) using make-bcache on
> > ARM64 server which has kernel enable 64K page size. However, the
> > bcach0 disappeared after the server reboot
On Tue, Apr 05, 2016 at 12:12:27PM -0400, Mike Snitzer wrote:
> Anyway, as Zdenek effectively: said dm-cache isn't a writecache. If you
> need a writecache then bcache is the only option as of now. Though
> there is an emerging DM writecache target that has stalled but can be
> revisited, see:
>
On Wed, Feb 24, 2016 at 10:48:10AM +0800, Ming Lei wrote:
> On Tue, Feb 23, 2016 at 10:54 PM, Mike Snitzer wrote:
> > On Mon, Feb 22 2016 at 9:55pm -0500,
> > Ming Lei wrote:
> >
> >> On Tue, Feb 23, 2016 at 6:58 AM, Kent Overstreet
> >> wrote:
> >
On Sun, Feb 21, 2016 at 05:40:59PM +0800, Ming Lei wrote:
> On Sun, Feb 21, 2016 at 2:43 PM, Ming Lin-SSI wrote:
> >>-Original Message-
> >
> > So it's almost already "per request_queue"
>
> Yes, that is because of the following line:
>
> q->bio_split = bioset_create(BIO_POOL_SIZE, 0);
>
er since commit dbba42d8a).
> > >
> > > Well, sorry about that. Note that l-k is on the cc list, so hopefully
> > > the right person sees it too.
> > >
> > > Ok, let me check... it seems that
> > > 54efd50bfd873e2dbf784e0b21a8027ba4
42 matches
Mail list logo
