On Thu, 2019-08-08 at 23:08 +0200, Douglas Gilbert wrote:
> On 2019-08-08 9:10 p.m., James Bottomley wrote:
> > On Wed, 2019-08-07 at 13:42 +0200, Douglas Gilbert wrote:
> > > This patchset extends the SCSI generic (sg) driver found in
> > > lk 5.3 . The sg driver ha
On Wed, 2019-08-07 at 13:42 +0200, Douglas Gilbert wrote:
> This patchset extends the SCSI generic (sg) driver found in
> lk 5.3 . The sg driver has a version number which is visible
> via ioctl(SG_GET_VERSION_NUM) and is bumped from 3.5.36 to
> 4.0.03 by this patchset. The additions and changes a
On Tue, 2019-05-21 at 09:01 +0200, Christoph Hellwig wrote:
> We currently fail to update the front/back segment size in the bio
> when
> deciding to allow an otherwise gappy segement to a device with a
> virt boundary. The reason why this did not cause problems is that
> devices with a virt bound
On Thu, 2019-06-13 at 15:26 -0400, Douglas Gilbert wrote:
> On 2019-06-13 12:28 p.m., James Bottomley wrote:
> > On Thu, 2019-06-13 at 12:07 -0400, Douglas Gilbert wrote:
> > > On 2019-06-13 11:31 a.m., Bart Van Assche wrote:
> >
> > [...]
> > > >
On Thu, 2019-06-13 at 12:07 -0400, Douglas Gilbert wrote:
> On 2019-06-13 11:31 a.m., Bart Van Assche wrote:
[...]
> > Please explain what makes you think that part_nr_sects_read() must
> > be protected
> > by an RCU read lock.
>
> Dear reviewer,
> Please rephrase the above sentence without the a
On Thu, 2019-04-11 at 14:52 +0200, Vlastimil Babka wrote:
> Hi,
>
> here's a late topic for discussion that came out of my patchset [1].
> It would likely have to involve all three groups, as FS/IO people
> would benefit, but it's MM area.
>
> Background:
> The recent thread [2] inspired me to lo
i: sd: Contribute to randomness when running
rotational device")
Cc: sta...@vger.kernel.org
Signed-off-by: James Bottomley
---
I updated this slightly over the original proposal so we set the flags
even if the device doesn't have any VPD pages, so it should work for
very old disks.
di
On Mon, 2019-02-11 at 19:50 -0700, Jens Axboe wrote:
> On 2/11/19 7:13 PM, James Bottomley wrote:
> > On Mon, 2019-02-11 at 09:31 -0700, Jens Axboe wrote:
> > > On 2/11/19 9:28 AM, James Bottomley wrote:
> > > > On Mon, 2019-02-11 at 08:46 -0700, Jens Axboe wrote
On Tue, 2019-02-12 at 03:37 +, Elliott, Robert (Persistent Memory)
wrote:
> > -Original Message-
> > From: linux-kernel-ow...@vger.kernel.org > ow...@vger.kernel.org> On Behalf Of Jens Axboe
> > Sent: Monday, February 11, 2019 8:50 PM
> > To: James Bot
On Mon, 2019-02-11 at 09:31 -0700, Jens Axboe wrote:
> On 2/11/19 9:28 AM, James Bottomley wrote:
> > On Mon, 2019-02-11 at 08:46 -0700, Jens Axboe wrote:
> > > On 2/11/19 8:42 AM, James Bottomley wrote:
> > > > On Mon, 2019-02-11 at 08:28 -0700, Jens Axboe wrote
On Mon, 2019-02-11 at 08:46 -0700, Jens Axboe wrote:
> On 2/11/19 8:42 AM, James Bottomley wrote:
> > On Mon, 2019-02-11 at 08:28 -0700, Jens Axboe wrote:
> > > On 2/11/19 8:25 AM, James Bottomley wrote:
> > > > On Sun, 2019-02-10 at 09:35 -0700, Jens Axboe wrote
On Mon, 2019-02-11 at 08:28 -0700, Jens Axboe wrote:
> On 2/11/19 8:25 AM, James Bottomley wrote:
> > On Sun, 2019-02-10 at 09:35 -0700, Jens Axboe wrote:
> > > On 2/10/19 9:25 AM, James Bottomley wrote:
> > > > On Sun, 2019-02-10 at 09:05 -0700, Jens Axboe wrote
On Sun, 2019-02-10 at 09:35 -0700, Jens Axboe wrote:
> On 2/10/19 9:25 AM, James Bottomley wrote:
> > On Sun, 2019-02-10 at 09:05 -0700, Jens Axboe wrote:
> > > On 2/10/19 8:44 AM, James Bottomley wrote:
> > > > On Sun, 2019-02-10 at 10:17 +0100, Mikael Pettersson
On Sun, 2019-02-10 at 09:05 -0700, Jens Axboe wrote:
> On 2/10/19 8:44 AM, James Bottomley wrote:
> > On Sun, 2019-02-10 at 10:17 +0100, Mikael Pettersson wrote:
> > > On Sat, Feb 9, 2019 at 7:19 PM James Bottomley
> > > wrote:
> >
> > [...]
> > >
On Sun, 2019-02-10 at 10:17 +0100, Mikael Pettersson wrote:
> On Sat, Feb 9, 2019 at 7:19 PM James Bottomley
> wrote:
[...]
> > I think the reason for this is that the block mq path doesn't feed
> > the kernel entropy pool correctly, hence the need to install an
> >
On Sat, 2019-02-09 at 18:04 +0100, Mikael Pettersson wrote:
> 4.20 and earlier kernels boot fine on my Sun Blade 2500 (UltraSPARC
> IIIi), but the 5.0-rc kernels consistently experience a 5 minute
> delay
> late during boot, after enabling networking but before allowing user
> logins. E.g. 5.0-rc5
On Sun, 2018-12-30 at 01:06 -0800, Christoph Hellwig wrote:
> On Thu, Dec 27, 2018 at 11:09:44AM -0500, Mike Snitzer wrote:
> > - Fix various DM targets to check for device sector overflow if
> > CONFIG_LBDAF is not set.
>
> Question to Jens and Linus:
>
> is there any good reason to keep the C
On Fri, 2018-04-20 at 16:44 -0600, Anatoliy Glagolev wrote:
>
> > This patch isn't applyable because your mailer has changed all the
> > tabs to spaces.
> >
> > I also think there's no need to do it this way. I think what we
> > need is for fc_bsg_remove() to wait until the bsg queue is
> > dra
On Thu, 2018-04-19 at 15:10 -0700, Anatoliy Glagolev wrote:
> Updated: rebased on recent Linux, cc-ed maintainers per instructions
> in MAINTAINERS file
>
> From df939b80d02bf37b21efaaef8ede86cfd39b0cb8 Mon Sep 17 00:00:00
> 2001
> From: Anatoliy Glagolev
> Date: Thu, 19 Apr 2018 15:06:06 -0600
>
On Mon, 2018-04-16 at 20:12 -0700, Kees Cook wrote:
> I still haven't figured this out, though... any have a moment to look
> at this?
Just to let you know you're not alone ... but I can't make any sense of
this either. The bfdq is the elevator_data, which is initialised when
the scheduler is att
On Sat, 2018-03-10 at 14:29 +0100, Stephen Kitt wrote:
> Hi Bart,
>
> On Fri, 9 Mar 2018 22:47:12 +, Bart Van Assche c.com>
> wrote:
> >
> > On Fri, 2018-03-09 at 23:33 +0100, Stephen Kitt wrote:
> > >
> > > +/*
> > > + * SCSI command sizes are as follows, in bytes, for fixed size
> > > com
On Mon, 2018-01-29 at 14:00 -0700, Jens Axboe wrote:
> On 1/29/18 1:56 PM, James Bottomley wrote:
> >
> > On Mon, 2018-01-29 at 23:46 +0800, Ming Lei wrote:
> > [...]
> > >
> > > 2. When to enable SCSI_MQ at default again?
> >
> > I'
On Mon, 2018-01-29 at 23:46 +0800, Ming Lei wrote:
[...]
> 2. When to enable SCSI_MQ at default again?
I'm not sure there's much to discuss ... I think the basic answer is as
soon as Christoph wants to try it again.
> SCSI_MQ is enabled on V3.17 firstly, but disabled at default. In
> V4.13-rc1, i
On Sat, 2018-01-27 at 09:37 +0100, Jan Tulak wrote:
> Springfield is a collection of projects unifying multiple levels of
> the storage stack and providing a general API for automation, health
> and status monitoring, as well as sane and easy configuration across
> multiple levels of the storage st
On Tue, 2018-01-16 at 18:23 -0500, Theodore Ts'o wrote:
> On Tue, Jan 16, 2018 at 06:52:40AM -0800, Matthew Wilcox wrote:
> >
> >
> > I see the improvements that Facebook have been making to the nbd
> > driver, and I think that's a wonderful thing. Maybe the outcome of
> > this topic is simply:
On Thu, 2017-12-21 at 10:02 -0700, Jens Axboe wrote:
> On 12/21/17 9:42 AM, Bruno Wolff III wrote:
> >
> > On Thu, Dec 21, 2017 at 23:48:19 +0800,
> > weiping zhang wrote:
> > >
> > > >
> > > > output you want. I never saw it for any kernels I compiled
> > > > myself. Only when I test kernels
On Wed, 2017-12-06 at 00:38 +0800, Ming Lei wrote:
> On Tue, Dec 05, 2017 at 04:22:33PM +, Bart Van Assche wrote:
> >
> > On Tue, 2017-12-05 at 13:00 +0800, Ming Lei wrote:
> > >
> > > No, do not mix two different things in one patch, especially the
> > > fix part need to be backported to sta
On Wed, 2017-11-15 at 18:09 +0800, Ming Lei wrote:
> On Tue, Nov 14, 2017 at 10:14:52AM -0800, James Bottomley wrote:
> >
> > On Tue, 2017-11-14 at 08:55 +0800, Ming Lei wrote:
> > >
> > > Hi James,
> > >
> > > On Mon, Nov
On Tue, 2017-11-14 at 08:55 +0800, Ming Lei wrote:
> Hi James,
>
> On Mon, Nov 13, 2017 at 10:55:52AM -0800, James Bottomley wrote:
> >
> > On Sat, 2017-11-11 at 10:43 +0800, Ming Lei wrote:
> > >
> > > So from CPU1's review, cmd->cmnd is in a rem
On Sat, 2017-11-11 at 10:43 +0800, Ming Lei wrote:
> On Fri, Nov 10, 2017 at 08:51:58AM -0800, James Bottomley wrote:
> >
> > On Fri, 2017-11-10 at 17:01 +0800, Ming Lei wrote:
> > >
> > > cmd->cmnd can be allocated/freed dynamically in case of
> > >
nic - not syncing: Fatal exception
> [ 252.963007] Dumping ftrace buffer:
> [ 252.963007](ftrace buffer empty)
> [ 252.963007] Kernel Offset: disabled
> [ 252.963007] ---[ end Kernel panic - not syncing: Fatal exception
>
> Fixes: 0eebd005dd07(scsi: Implement blk_mq_ops.show_r
e_name+0x1a/0x1c0 RSP:
> c90001bd3c50
> [ 252.963007] CR2:
> [ 252.963007] ---[ end trace 83c5bddfbaa6573c ]---
> [ 252.963007] Kernel panic - not syncing: Fatal exception
> [ 252.963007] Dumping ftrace buffer:
> [ 252.963007] (ftrace buffer empty)
> [
On Wed, 2017-11-08 at 09:15 +0800, Ming Lei wrote:
> On Wed, Nov 08, 2017 at 01:06:44AM +, Bart Van Assche wrote:
> >
> > On Wed, 2017-11-08 at 08:59 +0800, Ming Lei wrote:
> > >
> > > On Tue, Nov 07, 2017 at 04:13:48PM +, Bart Van Assche wrote:
> > > >
> > > > On Tue, 2017-11-07 at 23:2
On Fri, 2017-08-11 at 01:11 -0700, Christoph Hellwig wrote:
> [+ Martin and linux-scsi]
>
> Given that we need this big pile and a few bfq fixes to avoid
> major regressesions I'm tempted to revert the default to scsi-mq
> for 4.14, but bring it back a little later for 4.15.
>
> What do you think
On Wed, 2017-05-10 at 15:24 +0200, Hannes Reinecke wrote:
> sg_io() is using msecs_to_jiffies() to convert a passed in timeout
> value (in milliseconds) to a jiffies value. However, if the value
> is too large msecs_to_jiffies() will return MAX_JIFFY_OFFSET, which
> will be truncated to -2 and caus
On Fri, 2017-04-21 at 14:30 -0700, Kees Cook wrote:
> On Fri, Apr 21, 2017 at 2:27 PM, James Bottomley
> wrote:
> > On Fri, 2017-04-21 at 13:22 -0700, Kees Cook wrote:
> > > On Fri, Apr 21, 2017 at 12:55 PM, Eric Biggers <
> > > ebigge...@gmail.com>
> &
On Fri, 2017-04-21 at 13:22 -0700, Kees Cook wrote:
> On Fri, Apr 21, 2017 at 12:55 PM, Eric Biggers
> wrote:
> > > > Of course, having extra checks behind a debug option is fine.
> > > > But they should not be part of the base feature; the base
> > > > feature should just be mitigation of ref
On Thu, 2017-03-23 at 14:55 +0100, Christoph Hellwig wrote:
> On Thu, Mar 23, 2017 at 09:47:41AM -0400, James Bottomley wrote:
> > > The current implementation already has the issue of that it does
> > > corrupt user data reliably if the using SG_IO for WRITE SAME
> >
On Wed, 2017-03-22 at 19:19 +0100, Christoph Hellwig wrote:
> On Tue, Mar 21, 2017 at 02:59:01PM -0400, Tejun Heo wrote:
> > I do like the fact that this is a lot simpler than the previous
> > implementation but am not quite sure we want to deviate
> > significantly from what we do for other comma
On Wed, 2017-03-08 at 17:55 -0500, Tejun Heo wrote:
> Hello,
>
> On Wed, Mar 08, 2017 at 05:48:31PM +0100, Jan Kara wrote:
> > @@ -710,6 +710,11 @@ static void cgwb_bdi_destroy(struct
> > backing_dev_info *bdi)
> > */
> > atomic_dec(&bdi->usage_cnt);
> > wait_event(cgwb_release_wait,
On Tue, 2017-03-07 at 15:41 +0100, Jan Kara wrote:
> On Mon 06-03-17 09:25:42, James Bottomley wrote:
> > On Mon, 2017-03-06 at 17:13 +0100, Jan Kara wrote:
> > > On Mon 06-03-17 07:44:55, James Bottomley wrote:
> ...
> > > > > Sure. The call trace is
On Mon, 2017-03-06 at 16:14 +0100, Jan Kara wrote:
> On Mon 06-03-17 06:35:21, James Bottomley wrote:
> > On Mon, 2017-03-06 at 13:01 +0100, Jan Kara wrote:
> > > On Mon 06-03-17 11:27:33, Jan Kara wrote:
> > > > Hi,
> > > >
> > > > On Sun 05-
On Mon, 2017-03-06 at 17:13 +0100, Jan Kara wrote:
> On Mon 06-03-17 07:44:55, James Bottomley wrote:
> > On Mon, 2017-03-06 at 16:14 +0100, Jan Kara wrote:
> > > On Mon 06-03-17 06:35:21, James Bottomley wrote:
> > > > On Mon, 2017-03-06 at 13:01 +0100, Jan Kara wr
On Mon, 2017-03-06 at 13:01 +0100, Jan Kara wrote:
> On Mon 06-03-17 11:27:33, Jan Kara wrote:
> > Hi,
> >
> > On Sun 05-03-17 10:21:11, Wu Fengguang wrote:
> > > FYI next-20170303 is good while mainline is bad with this error.
> > > The attached reproduce-* may help reproduce the issue.
> >
> >
On Mon, 2017-02-27 at 08:03 +1100, NeilBrown wrote:
> On Sun, Feb 26 2017, James Bottomley wrote:
>
> > [added linux-scsi and linux-block because this is part of our error
> > handling as well]
> > On Sun, 2017-02-26 at 09:42 -0500, Jeff Layton wrote:
> > > Prop
[added linux-scsi and linux-block because this is part of our error
handling as well]
On Sun, 2017-02-26 at 09:42 -0500, Jeff Layton wrote:
> Proposing this as a LSF/MM TOPIC, but it may turn out to be me just
> not understanding the semantics here.
>
> As I was looking into -ENOSPC handling in c
On Mon, 2017-02-20 at 17:56 +0100, Peter Zijlstra wrote:
> On Mon, Feb 20, 2017 at 07:41:01AM -0800, 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 t
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
> > patches convert various refcounters in the block susystem from
> > atomic_t to ref
On Sun, 2017-02-19 at 18:15 -0700, Jens Axboe wrote:
> On 02/19/2017 06:09 PM, Bart Van Assche wrote:
> > On 02/19/2017 04:11 PM, Jens Axboe wrote:
> > > - Removal of the BLOCK_PC support in struct request, and
> > > refactoring of
> > > carrying SCSI payloads in the block layer. This cleans up t
On Fri, 2017-02-17 at 16:30 -0800, Omar Sandoval wrote:
> Hi, everyone,
>
> As per $SUBJECT, I can cause a crash on v4.10-rc8, Jens' block/for
> -next,
> and Jan's bdi branch [1] by doing this:
>
> # lsscsi
> [0:0:0:0]diskQEMU QEMU HARDDISK2.5+ /dev/sda
> # echo 0:0:0:0 > /sys/bu
On Mon, 2017-02-06 at 21:09 -0700, Jens Axboe wrote:
> On 02/06/2017 05:14 PM, James Bottomley wrote:
> > On Sun, 2017-02-05 at 21:13 -0800, Dan Williams wrote:
> > > On Sun, Feb 5, 2017 at 1:13 AM, Christoph Hellwig
> > > wrote:
> > > > Dan,
> > >
On Mon, 2017-02-06 at 21:42 -0800, Dan Williams wrote:
> On Mon, Feb 6, 2017 at 8:09 PM, Jens Axboe wrote:
> > On 02/06/2017 05:14 PM, James Bottomley wrote:
> > > On Sun, 2017-02-05 at 21:13 -0800, Dan Williams wrote:
> > > > On Sun, Feb 5, 2017 at 1:13 AM, Ch
On Tue, 2017-02-07 at 16:09 +, Jim Mostek via Lsf-pc wrote:
> wondering about the upcoming Linux Storage Filesystem & MM summint in
> March. LSF/MM Question
>
> What presentations are there so far?
LSF/MM is not really a conference, it's a summit. That means it's
going to be discussion drive
On Sun, 2017-02-05 at 21:13 -0800, Dan Williams wrote:
> On Sun, Feb 5, 2017 at 1:13 AM, Christoph Hellwig wrote:
> > Dan,
> >
> > can you please quote your emails? I can't find any content
> > inbetween all these quotes.
>
> Sorry, I'm using gmail, but I'll switch to attaching the logs.
>
>
On Tue, 2017-01-31 at 10:02 -0800, Jens Axboe wrote:
> On 01/31/2017 07:57 AM, Christoph Hellwig wrote:
> > [1] which were a pain in the ass to untangle and debug during
> > development, it's really time for it to die..
>
> Outside of the patch series in question, how to we expedite the
> euthana
On Mon, 2017-01-16 at 11:33 +0800, Guoqing Jiang wrote:
>
> On 01/10/2017 12:38 AM, Coly Li wrote:
> > Hi Folks,
> >
> > I'd like to propose a general md raid discussion, it is quite
> > necessary for most of active md raid developers sit together to
> > discuss current challenge of Linux softw
On Thu, 2017-01-12 at 11:35 +0900, Damien Le Moal wrote:
> > Just a note for the poor admin looking after the lists: to find all
> > the ATTEND and TOPIC requests for the lists I fold up the threads
> > to the top. If you frame your attend request as a reply, it's
> > possible it won't get coun
On Thu, 2017-01-12 at 10:33 +0900, Damien Le Moal wrote:
> Hello,
>
> A long discussion on the list followed this initial topic proposal
> from Matias. I think this is a worthy topic to discuss at LSF in
> order to steer development of the zoned block device interface in the
> right direction.
On Tue, 2016-12-13 at 13:55 -0500, Jerome Glisse wrote:
> On Tue, Dec 13, 2016 at 10:20:52AM -0800, James Bottomley wrote:
> > On Tue, 2016-12-13 at 13:15 -0500, Jerome Glisse wrote:
> > > I would like to discuss un-addressable device memory in the
> > > context
&g
On Tue, 2016-12-13 at 13:15 -0500, Jerome Glisse wrote:
> I would like to discuss un-addressable device memory in the context
> of filesystem and block device. Specificaly how to handle write-back,
> read, ... when a filesystem page is migrated to device memory that
> CPU can not access.
>
> I i
On Thu, 2016-12-08 at 13:26 +0100, Michal Hocko wrote:
> On Wed 07-12-16 06:57:06, James Bottomley wrote:
> [...]
> > Just on this point, since there seems to be a lot of confusion: lsf
> > -pc
> > is the list for contacting the programme committee, so you ca
On Thu, 2016-12-01 at 09:11 -0500, Jeff Layton wrote:
> 1) Proposals for agenda topics should be sent before January 15th,
> 2016 to:
>
> lsf...@lists.linux-foundation.org
>
> and cc the Linux list or lists that are relevant for the topic in
> question:
>
> ATA: linux-...@vger.kernel.
On Tue, 2016-09-27 at 09:43 -0700, Bart Van Assche wrote:
> On 09/27/2016 09:31 AM, Steve Wise wrote:
> > > @@ -2079,11 +2075,15 @@ EXPORT_SYMBOL_GPL(nvme_kill_queues);
> > > void nvme_stop_queues(struct nvme_ctrl *ctrl)
> > > {
> > > struct nvme_ns *ns;
> > > + struct request_queue *q;
> > >
On Mon, 2016-08-29 at 11:16 -0700, Bart Van Assche wrote:
> On 08/14/2016 10:21 AM, James Bottomley wrote:
> > diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
> > index d3e852a..222771d 100644
> > --- a/drivers/scsi/sd.c
> > +++ b/drivers/scsi/sd.c
> > @
On Sat, 2016-08-13 at 11:27 -0700, Dan Williams wrote:
> On Sat, Aug 13, 2016 at 10:43 AM, James Bottomley
> wrote:
> > On Sat, 2016-08-13 at 09:29 -0700, Dan Williams wrote:
> > > On Sat, Aug 13, 2016 at 8:23 AM, James Bottomley
> > > wrote:
> > > &g
On Sat, 2016-08-13 at 09:29 -0700, Dan Williams wrote:
> On Sat, Aug 13, 2016 at 8:23 AM, James Bottomley
> wrote:
> > It does? The race is the fact that the parent can be removed
> > before the child meaning if the parent name is re-registered before
> > the child dies
On Fri, 2016-08-12 at 21:57 -0700, Dan Williams wrote:
> On Fri, Aug 12, 2016 at 5:29 PM, Dan Williams <
> dan.j.willi...@intel.com> wrote:
> > On Fri, Aug 12, 2016 at 5:17 PM, James Bottomley
> > wrote:
> > > On Fri, 2016-08-12 at 14:29 -0700, Dan Williams wrot
On Fri, 2016-08-12 at 14:29 -0700, Dan Williams wrote:
> Before spending effort trying to flush the destruction of old bdi
> instances before new ones are registered, is it rather time to
> complete the conversion of sd to only use dynamically allocated devt?
Do we have to go that far? Surely you
68 matches
Mail list logo
