On Sat, Jun 14, 2014 at 08:13:39PM +0930, David Newall wrote:
> I'm running a qemu virtual machine, 2 x i686 with 2GB RAM. VM's disks are
> managed via LVM2. Most disk activity is on one LV, formatted as ext4.
> Backups are taken using snapshots, and at the time of the problem that I am
> about
On Sat, Jun 14, 2014 at 08:13:39PM +0930, David Newall wrote:
I'm running a qemu virtual machine, 2 x i686 with 2GB RAM. VM's disks are
managed via LVM2. Most disk activity is on one LV, formatted as ext4.
Backups are taken using snapshots, and at the time of the problem that I am
about to
On 03/14/2014 02:13 PM, Mike Snitzer wrote:
> Yeah, not sure why single path scsi_debug "just works", maybe it is a
> "feature" of the older multipathd I have kicking around?, but for basic
> data path testing scsi_debug is a quick means to an end. I can look
> closer at _why_ it gets multipathd
On 03/14/2014 02:13 PM, Mike Snitzer wrote:
Yeah, not sure why single path scsi_debug just works, maybe it is a
feature of the older multipathd I have kicking around?, but for basic
data path testing scsi_debug is a quick means to an end. I can look
closer at _why_ it gets multipathd in a
to cciss_read_capacity in commit
98c. Emitting device and block size information at KERN_INFO on
each read_capacity() leads to a lot of log noise.
Signed-off-by: Bryn M. Reeves
>From da8267e5452e03158da8dd27026fb7188342d653 Mon Sep 17 00:00:00 2001
From: "Bryn M. Reeves"
Date: Fri, 7 J
to cciss_read_capacity in commit
98c. Emitting device and block size information at KERN_INFO on
each read_capacity() leads to a lot of log noise.
Signed-off-by: Bryn M. Reeves b...@redhat.com
From da8267e5452e03158da8dd27026fb7188342d653 Mon Sep 17 00:00:00 2001
From: Bryn M. Reeves b...@redhat.com
On 02/01/2013 11:13 AM, Tao Ma wrote:
You don't mention the versions of the kernel and driver you're using -
if the system is in production I would suggest contacting who ever
normally provides support for the kernel and distribution that you are
running.
We use CentOS6.2 and the kernel version
On 02/01/2013 09:59 AM, Tao Ma wrote:
yes, but the result is the same. It will do some IO first which will
cause this command hang.
You seem to have a problem with either the device/adapter or in the
driver. The backtrace you posted shows that jbd2 (ext4) is still waiting
on IO that's been
On 02/01/2013 07:54 AM, Bart Van Assche wrote:
* proc_scsi_write - handle writes to /proc/scsi/scsi
* @file: not used
* @buf: buffer to write
* @length: length of buf, at most PAGE_SIZE
* @ppos: not used
*
* Description: this provides a legacy mechanism to add or remove
* devices
On 02/01/2013 07:54 AM, Bart Van Assche wrote:
* proc_scsi_write - handle writes to /proc/scsi/scsi
* @file: not used
* @buf: buffer to write
* @length: length of buf, at most PAGE_SIZE
* @ppos: not used
*
* Description: this provides a legacy mechanism to add or remove
* devices
On 02/01/2013 09:59 AM, Tao Ma wrote:
yes, but the result is the same. It will do some IO first which will
cause this command hang.
You seem to have a problem with either the device/adapter or in the
driver. The backtrace you posted shows that jbd2 (ext4) is still waiting
on IO that's been
On 02/01/2013 11:13 AM, Tao Ma wrote:
You don't mention the versions of the kernel and driver you're using -
if the system is in production I would suggest contacting who ever
normally provides support for the kernel and distribution that you are
running.
We use CentOS6.2 and the kernel version
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dave Hansen wrote:
> On Wed, 2008-01-16 at 00:52 -0800, Andrew Morton wrote:
>> On Thu, 01 Nov 2007 16:08:31 -0700 Dave Hansen <[EMAIL PROTECTED]> wrote:
>>> Replace all callers with open_namei() directly, and move the
>>> nameidata stack allocation
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dave Hansen wrote:
On Wed, 2008-01-16 at 00:52 -0800, Andrew Morton wrote:
On Thu, 01 Nov 2007 16:08:31 -0700 Dave Hansen [EMAIL PROTECTED] wrote:
Replace all callers with open_namei() directly, and move the
nameidata stack allocation into
14 matches
Mail list logo
