jejb@jarvis:~/git/linux/drivers/scsi> git grep container_of|wc -l
496
So we really don't want to encourage wrapping them all because the
churn would be unbelievable and the gain minute. So why should this
one case especially be wrapped when we don't want to wrap the others?
James
-
NT_DESTROY_CONN event sent by the iscsi daemon. Obviously if
the daemon goes haywire and doesn't shut down the connection before
sending the destroy event, we may get the crash, but I would be
inclined to say fix the daemon.
James
tlink and the filters, right?
The other list that would take a more generic view is the containers
one contain...@lists.linux-foundation.org because that's where most
namespace stuff ends up.
James
> Thank you,
> Chris
>
> On Tue, Oct 31, 2017 at 03:40:55PM -0700, Chris Leech wrote
On Thursday, July 28, 2016 at 1:03:18 PM UTC-4, Chris Leech wrote:
>
> On Thu, Jul 28, 2016 at 02:50:54AM -0700, james harvey wrote:
> > Am I doing something wrong to get iscsid to automatically login to
> certain
> > nodes, or am I not understanding what the .startup
Sorry for cross-posting to github, just saw several messages saying to use
the mailing list instead.
I made a similar bug report to the linux-rdma mailing list about a year
ago, and never followed up here. I got a response that this is an
open-iscsi issue not a kernel issue. (See
haps we should rather
fix this by making the next session id a target local quantity?
James
--
You received this message because you are subscribed to the Google Groups
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to open-isc
Anna <s-a...@ti.com>
>
> Interesting.
> Will the same apply to e.g. sd_index_ida in drivers/scsi/sd.c
> or iscsi_sess_ida in drivers/scsi/scsi_transport_iscsi.c?
>
> If no, why not?
>
> One doesn't generally expect to have to free global variables.
> Maybe we should forb
On Thu, 2015-09-17 at 19:06 +0300, Michael S. Tsirkin wrote:
> On Thu, Sep 17, 2015 at 07:15:44AM -0700, James Bottomley wrote:
> > On Thu, 2015-09-17 at 08:33 +0300, Michael S. Tsirkin wrote:
> > > On Wed, Sep 16, 2015 at 07:29:17PM -0500, Suman Anna wrote:
> > > >
On Thu, 2015-09-17 at 13:15 -0400, Tejun Heo wrote:
> Hello,
>
> On Thu, Sep 17, 2015 at 09:48:37AM -0700, James Bottomley wrote:
> > Well, there's an easy fix for that. We could have ida_remove() actually
> > free the bitmap and not cache it if it's the last layer. T
approaching the point where the
fineness of our lock granularity is hurting performance, so it's worth
re-asking the question of whether just dumping all the lock latency by
single CPU binding is a worthwhile exercise.
James
--
You received this message because you are subscribed to the Google Groups
On Thu, 2015-01-08 at 14:57 -0800, Nicholas A. Bellinger wrote:
On Thu, 2015-01-08 at 14:29 -0800, James Bottomley wrote:
On Thu, 2015-01-08 at 14:16 -0800, Nicholas A. Bellinger wrote:
On Thu, 2015-01-08 at 08:50 +0100, Bart Van Assche wrote:
On 01/07/15 22:39, Mike Christie wrote
On Thu, 2015-01-08 at 21:03 -0800, Nicholas A. Bellinger wrote:
On Thu, 2015-01-08 at 15:22 -0800, James Bottomley wrote:
On Thu, 2015-01-08 at 14:57 -0800, Nicholas A. Bellinger wrote:
On Thu, 2015-01-08 at 14:29 -0800, James Bottomley wrote:
On Thu, 2015-01-08 at 14:16 -0800, Nicholas
to be a bottleneck which wouldn't
necessarily be mitigated simply by allowing everything to proceed out of
order after this point.
James
--
You received this message because you are subscribed to the Google Groups
open-iscsi group.
To unsubscribe from this group and stop receiving emails from it, send
connection selection in
the iscsi layer, then I think we want to leave that for after the
initial merge, so people can argue about that separately.
Well, you're right, we can argue about it later, but if it's just round
robin, why would it be better done in the initator rather than dm?
James
on device bring up as this one is.
James
--
You received this message because you are subscribed to the Google Groups
open-iscsi group.
To unsubscribe from this group and stop receiving emails from it, send an email
to open-iscsi+unsubscr...@googlegroups.com.
To post to this group, send email
This is a bit tricky, since AMD laid off the team who were maintaining
this, but I added to the cc' one of the original maintainers in the
hopes they can take a look.
James
On Tue, 2013-02-19 at 18:30 -0800, Eddie Wai wrote:
Hello,
For a 64-bit DMA capable PCIe storage HBA running under
I appear to be having a similar issue with a Citrix XenServer host.
Using the XenAPI I attempt to launch a number of VMs at the same
time. Each VM is backed by it's own iscsi target so there is a bunch
of logging in, discovery and session listing during this time.
Roughly 50% of the launches
8 is hardcoded.
Agreed, I skipped this one for now ... please resubmit against scsi-misc
if more work is needed.
Thanks,
James
--
You received this message because you are subscribed to the Google Groups
open-iscsi group.
To post to this group, send email to open-iscsi@googlegroups.com
On Mon, 2011-03-14 at 20:09 -0700, Greg KH wrote:
On Mon, Mar 14, 2011 at 10:26:05PM -0400, James Bottomley wrote:
On Sat, 2011-03-12 at 23:23 +0300, Vasiliy Kulikov wrote:
Vasiliy Kulikov (20):
mach-ux500: mbox-db5500: world-writable sysfs fifo file
leds: lp5521: world-writable
landed up in the privilege
separation arena using capabilities. That means that world writeable
files aren't necessarily a problem as long as the correct capabilities
checks are in place, right?
James
--
You received this message because you are subscribed to the Google Groups
open-iscsi group
On Tue, 2011-03-15 at 07:18 -0700, Greg KH wrote:
On Tue, Mar 15, 2011 at 07:50:28AM -0400, James Bottomley wrote:
On Mon, 2011-03-14 at 20:09 -0700, Greg KH wrote:
There are no capability checks on sysfs files right now, so these all
need to be fixed.
That statement is true
On Tue, 2011-03-15 at 19:08 +0300, Vasiliy Kulikov wrote:
On Tue, Mar 15, 2011 at 07:50 -0400, James Bottomley wrote:
1. Did anyone actually check for capabilities before assuming world
writeable files were wrong?
I didn't check all these files as I haven't got these hardware
a 7th disk I also have no problems with that
disk. The size I use on the 6th disk doesn't seem to matter. I've
tested it with anywhere from 50GB to 360GB and get the error with all
disk sizes.
How can I resolve the Found duplicate PV warning/error?
--
James Hammer
jham...@callone.com
312-681
Mike Christie wrote:
On 03/23/2010 10:13 AM, James Hammer wrote:
Mike Christie wrote:
On 03/22/2010 03:38 PM, James Hammer wrote:
Every time I reboot my server it hangs on the multipath devices.
The server is Debian based. I've had this problem with all kernels
I've
tried (2.6.18, 2.6.24
Mike Christie wrote:
On 03/22/2010 03:38 PM, James Hammer wrote:
Every time I reboot my server it hangs on the multipath devices.
The server is Debian based. I've had this problem with all kernels I've
tried (2.6.18, 2.6.24, 2.6.32). In /etc/multipath.conf, no_path_retry is
set to queue
Here
=linux-scsim=125725904205688w=2).
-- james s
--
You received this message because you are subscribed to the Google Groups
open-iscsi group.
To post to this group, send email to open-is...@googlegroups.com.
To unsubscribe from this group, send email to
open-iscsi+unsubscr...@googlegroups.com
: dm_send_uevents: kobject_uevent_env failed
device-mapper: multipath: Failing path 8:80.
device-mapper: uevent: dm_send_uevents: kobject_uevent_env failed
/snip
The server is then stuck there indefinitely.
What can I do to avoid this problem when rebooting?
Thanks.
-- James
--
You received
James Hammer wrote:
Every time I reboot my server it hangs on the multipath devices.
The server is Debian based. I've had this problem with all kernels
I've tried (2.6.18, 2.6.24, 2.6.32). In /etc/multipath.conf,
no_path_retry is set to queue
I found that if I set no_path_retry to its
had the bsg
infrastructure for the first need, you had to add very little to support it.
Thus, the main reason they are together is one of expediency. The first had to
be done, so it was very easy to use the same methodology for the second.
-- james s
--
You received this message because you
target on
the iscsi server.
Is there a way to specify a different node.startup value for different
networks in iscsid.conf ?
Thanks.
-- James
--
You received this message because you are subscribed to the Google Groups
open-iscsi group.
To post to this group, send email to open
Mike Christie wrote:
On 02/05/2010 12:05 PM, James Hammer wrote:
Is it possible to set different node.startup values per network in
iscsid.conf?
For example, I connect to an iscsi device over 4 interfaces:
eth0: 10.1.1.20/24
eth1: 172.19.1.20/24
eth2: 172.19.2.20/24
eth3: 172.19.3.20/24
I
checked
I've fixed it up. And the several other whitespace problems in the rest
of the patch set.
James
--
You received this message because you are subscribed to the Google Groups
open-iscsi group.
To post to this group, send email to open-is...@googlegroups.com.
To unsubscribe from
conclusion. Yes, I
don't like the replication either.
-- james s
Mike Christie wrote:
James Smart wrote:
This patch implements the same infrastructure as found in the FC transport
for sgio request/response handling.
The patch creates (and exports to userland) a new header - scsi_bsg_iscsi.h
[reposting to include open-iscsi list]
This patch implements the same infrastructure as found in the FC transport
for sgio request/response handling.
The patch creates (and exports to userland) a new header -
scsi_bsg_iscsi.h
-- james s
Signed-off-by: James Smart james.sm...@emulex.com
micheal jackson history
micheal jackson history
http://science2technologies.blogspot.com
http://science2technologies.blogspot.com
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
open-iscsi group.
To post to this
.
James
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
open-iscsi group.
To post to this group, send email to open-iscsi@googlegroups.com
To unsubscribe from this group, send email to
open-iscsi+unsubscr
this driver.
2. It includes useful and appropriate warnings for common bugs in
refcounted code, such as use of a freed reference.
James
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
open-iscsi group.
To post
Romantic Honeymoon Couple's Sexy Pics Videos here
Romantic Honeymoon Couple's Sexy Pics Videos here
http://prabhuearnings.blogspot.com
http://prabhuearnings.blogspot.com
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
to be allocated
within iscsi_segment.
Signed-off-by: Karen Xie k...@chelsio.com
Thanks for finding this.
Acked-by: Mike Christie micha...@cs.wisc.edu
Could one of you regenerate this against current git head, please, it
seems to have suffered from the iscsi to libiscsi move.
James
On Mon, 2008-02-18 at 17:08 +0200, Boaz Harrosh wrote:
But ... James? is
there any chance these can go into scsi-rc-fixes for the 2.6.25
kernel? The reason they are so late was mainly because of a fallout
in the merge process and a bug that was introduced because of that,
but they were
40 matches
Mail list logo
