sg:
> > ---
> > Buffer I/O error on dev dm-0, logical block 1310704, async page read
> > Buffer I/O error on dev dm-0, logical block 16, async page read
> > Buffer I/O error on dev dm-0, logical block 16, async page read
> > ---
> >
> > And bisect leads t
splitting multi-page bvec into segments, the max segment
> > limit may be reached, so the bio split need to be considered under
> > this situation too.
> >
> > Cc: Dave Chinner
> > Cc: Kent Overstreet
> > Cc: Mike Snitzer
> > Cc: dm-de...@redhat.co
field to set would create a cascade of churn
throughout kernel (and invariably many callers won't need the new field
initialized, so you keep passing 0 for more and more fields).
Nacked-by: Mike Snitzer
On Sun, May 20 2018 at 6:25pm -0400,
Kent Overstreet wrote:
> Jens - this series does the rest of the conversions that Christoph wanted, and
> drops bioset_create().
>
> Only lightly tested, but the changes are pretty mechanical. Based on your
> for-next tree.
By switching 'mempool_t *' to 'me
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 series does the rest of the conversions that Christoph wanted,
>
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, Mike Snitzer wrote:
> >>> On Sun, May 20 2018 at
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, Mike Snitzer wrote:
> >>> On Mon, May 21 2018
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, Mike Snitzer wrote:
> >>> On Mon, May 21 2018
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, Mike Snitzer wrote:
> >>> On Mon, May 21 2018
On Mon, May 21 2018 at 1:37pm -0400,
Kent Overstreet wrote:
>
> Uh, you came across as upset and paranoid to me too. Chalk it up to email? :)
Awesome. See how easy it is to make someone with purely constructive
questions and feedback come off as upset and paranoid?
The tipping point occurs w
On Tue, May 22 2018 at 2:41am -0400,
Christoph Hellwig wrote:
> On Mon, May 21, 2018 at 07:38:55PM -0400, Kent Overstreet wrote:
> > On Mon, May 21, 2018 at 02:24:32PM -0400, Mike Snitzer wrote:
> > > Every single data structure change in this series should be reviewed fo
On Fri, Apr 15 2016 at 3:15pm -0400,
mchri...@redhat.com wrote:
> The following patches begin to cleanup the request->cmd_flags and
> bio->bi_rw mess. We currently use cmd_flags to specify the operation,
> attributes and state of the request. For bi_rw we use it for similar
> info and also the p
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 have tigher control and explicit semantics for
> > block layer errors.
> >
> > All but t
blk_status_t *error)
{
struct cache *cache = ti->private;
unsigned long flags;
But I can let these go (will clean them up if/when I make changes to the
various locations in the future)...
You can add my s-o-b tag to all commits in this series that touch DM:
Signed-off-by: Mi
On Fri, Mar 20 2015 at 10:50am -0400,
Josef Bacik wrote:
> This creates a new target that is meant for file system developers to test
> file
> system integrity at particular points in the life of a file system. We
> capture
> all write requests and the data and log the requests and the data to
expertise but my
experience with this review should really underscore the need for more
eyes on this patch. That said, I do appreciate your effort on cleaning
this up!
For DM, please add Signed-off-by: Mike Snitzer once
you've folded in this patch, thanks!
diff --git a/drivers/md/dm-bufio.c
On Wed, Jun 10 2015 at 4:11am -0400,
Christoph Hellwig wrote:
> On Thu, Jun 04, 2015 at 11:31:07AM -0400, Mike Snitzer wrote:
> > This patch _really_ concerns me because just in DM alone I found you
> > took liberties that you shouldn't have and created a regression. First
On Wed, Jun 10 2015 at 11:26am -0400,
Mike Snitzer wrote:
> On Wed, Jun 10 2015 at 4:11am -0400,
> Christoph Hellwig wrote:
>
> > On Thu, Jun 04, 2015 at 11:31:07AM -0400, Mike Snitzer wrote:
> > > This patch _really_ concerns me because just in DM alone I found you
&
On Wed, Jun 10 2015 at 12:04pm -0400,
Christoph Hellwig wrote:
> On Wed, Jun 10, 2015 at 12:01:12PM -0400, Mike Snitzer wrote:
> > > I'll queue a patch to rename 'error' to 'error_bits' where appropriate.
> >
> > See:
> > https://git.kern
On Sun, Nov 07 2010 at 6:05pm -0500,
Andi Kleen wrote:
> On Sun, Nov 07, 2010 at 10:39:23PM +0100, Milan Broz wrote:
> > On 11/07/2010 08:45 PM, Andi Kleen wrote:
> > >> I read about barrier-problems and data getting to the partition when
> > >> using dm-crypt and several layers so I don't know
On Mon, Nov 08 2010 at 12:59pm -0500,
Chris Mason wrote:
> Excerpts from Mike Snitzer's message of 2010-11-08 09:58:09 -0500:
> > On Sun, Nov 07 2010 at 6:05pm -0500,
> > Andi Kleen wrote:
> >
> > > On Sun, Nov 07, 2010 at 10:39:23PM +0100, Milan Broz wrote:
> > > > On 11/07/2010 08:45 PM, And
On Wed, Dec 01 2010 at 11:05am -0500,
Matt wrote:
> On Mon, Nov 15, 2010 at 12:24 AM, Matt wrote:
> > On Sun, Nov 14, 2010 at 10:54 PM, Milan Broz wrote:
> >> On 11/14/2010 10:49 PM, Matt wrote:
> >>> only with the dm-crypt scaling patch I could observe the data-corruption
> >>
> >> even with v
On Wed, Dec 01 2010 at 3:45pm -0500,
Milan Broz wrote:
>
> On 12/01/2010 08:34 PM, Jon Nelson wrote:
> > Perhaps this is useful: for myself, I found that when I started using
> > 2.6.37rc3 that postgresql starting having a *lot* of problems with
> > corruption. Specifically, I noted zeroed page
On Sat, Dec 04 2010 at 2:18pm -0500,
Matt wrote:
> On Wed, Dec 1, 2010 at 10:23 PM, Mike Snitzer wrote:
> > Matt and Jon,
> >
> > If you'd be up to it: could you try testing your dm-crypt+ext4
> > corruption reproducers against the following
On Sun, Dec 05 2010 at 3:28pm -0500,
Andi Kleen wrote:
> > As another thought, what version of GCC are people using who are having
> > difficulty? Could this perhaps be a compiler-related issue?
>
> A compiler problem seems very unlikely here.
>
> What may be an useful experiment would be t
On Tue, Dec 07 2010 at 1:10pm -0500,
Jon Nelson wrote:
> I finally found some time to test this out. With 2.6.37-rc4 (openSUSE
> KOTD kernel) I easily encounter the issue.
>
> Using a virtual machine, I created a stock, minimal openSUSE 11.3 x86_64
> install, installed all updates, installed po
On Fri, Jul 15, 2011 at 8:58 AM, Ric Wheeler wrote:
> On 07/15/2011 12:34 PM, Chris Mason wrote:
>>
>> Excerpts from NeilBrown's message of 2011-07-15 02:33:54 -0400:
>>>
>>> On Thu, 14 Jul 2011 21:58:46 -0700 (PDT) da...@lang.hm wrote:
>>>
On Thu, 14 Jul 2011, Chris Mason wrote:
> E
On Mon, Dec 08 2014 at 5:32P -0500,
Josef Bacik wrote:
> This is my latest attempt at a target for testing power fail and fs
> consistency.
> This is based on the idea Zach Brown had where we could just walk through all
> the operations done to an fs in order to verify we're doing the correct t
On Wed, Feb 04 2015 at 1:41pm -0500,
Mike Snitzer wrote:
> @@ -527,9 +522,10 @@ static void normal_map_bio(struct dm_target *ti, struct
> bio *bio)
> struct log_writes_c *lc = ti->private;
>
> bio->bi_bdev = lc->dev->bdev;
> + // FIXME: why w
On Sat, Jan 10, 2009 at 1:44 AM, Nicholas Miell wrote:
> On Fri, 2009-01-09 at 20:05 -0800, Linus Torvalds wrote:
>>
>> On Fri, 9 Jan 2009, Nicholas Miell wrote:
>> >
>> > It's only too big if you always keep it in memory, and I wasn't
>> > suggesting that.
>>
>> Umm. We're talking kernel panics h
On Sat, Jan 10, 2009 at 10:34 AM, Ingo Molnar wrote:
>
> * Mike Snitzer wrote:
>
>> Yes, especially from someone who lacks the ability to properly configure
>> kdump. I'm fairly surprised others are giving you a free pass when you
>> keep asserting how broken kdu
On Sat, Jan 10, 2009 at 8:28 PM, Ingo Molnar wrote:
>
> Note, back when kdump was added to the kernel many moons ago i strongly
> supported it and helped out with the patches, etc. I still think it might
> have the potential to become big - but it needs a ton of tech and care to
> reach that level
On Sun, Jan 11, 2009 at 5:11 AM, Andreas Dilger wrote:
> On Jan 10, 2009 16:15 -0500, Theodore Ts'o wrote:
>> In my experience, there are very few kernel versions and hardware for
>> which kdump works. I've talked to the people who have to make kdump
>> work, and every 12-18 months, with a new s
33 matches
Mail list logo
