Hi All,
I'm glad to announce SCST 3.3 pre-release code freeze in the SCST SVN branch
3.3.x.
You can get it by command:
$ svn co https://scst.svn.sourceforge.net/svnroot/scst/branches/3.3.x
It is going to be released after few weeks of testing, if no significant issues
found.
SCST is alternat
Hi All,
I'm glad to announce SCST 3.2 has just been released
You can download it from http://scst.sourceforge.net/downloads.html
SCST is alternative SCSI target stack for Linux. SCST allows creation of
sophisticated
storage devices, which can provide advanced functionality, like replication,
t
Hi All,
I'm glad to announce SCST 3.2 pre-release code freeze in the SCST SVN branch
3.2.x.
You can get it by command:
$ svn co https://scst.svn.sourceforge.net/svnroot/scst/branches/3.2.x
It is going to be released after few weeks of testing, if no significant issues
found.
SCST is alternat
Nicholas A. Bellinger wrote on 01/27/2016 10:36 PM:
> On Wed, 2016-01-27 at 09:54 -0800, Bart Van Assche wrote:
>> Last year, during the 2015 LSF/MM summit, it has been decided that the
>> LIO/SCST merger project should proceed by sending the functionality
>> upstream that is present in SCST but
Hi All,
I'm glad to announce that SCST version 3.1 has just been released and available
for
download from http://scst.sourceforge.net/downloads.html.
Highlights for this release:
- Cluster support for SCSI reservations. This feature is essential for
initiator-side
clustering approaches based
Hi,
Bike & Snow wrote on 11/06/2015 10:55 AM:
> Hello Vlad
>
> Excellent news on all the updates.
>
> Regarding this:
> - QLogic target driver has been significantly improved.
>
> Does that mean I should stop building the QLogic target driver from here?
> git://git.qlogic.com/scst-qla2xxx.git <
Hi All,
I'm glad to announce SCST 3.1 pre-release code freeze in the SCST SVN branch
3.0.x.
You can get it by command:
$ svn co https://scst.svn.sourceforge.net/svnroot/scst/branches/3.1.x
It is going to be released after few weeks of testing, if no significant issues
found.
Highlights for t
I'm glad to announce that maintenance update for SCST and its drivers 3.0.1 has
just
been released and ready for download from
http://scst.sourceforge.net/downloads.html.
All SCST users are encouraged to update.
SCST is alternative SCSI target stack for Linux. SCST allows creation of
sophistica
Sagi Grimberg wrote on 01/08/2015 05:45 AM:
>> RFC 3720 namely requires that iSCSI numbering is
>> session-wide. This means maintaining a single counter for all MC/S
>> sessions. Such a counter would be a contention point. I'm afraid that
>> because of that counter performance on a multi-socket ini
Martin K. Petersen wrote on 12/11/2014 07:12 PM:
>>>>>> "Vlad" == Vladislav Bolkhovitin writes:
> Vlad> We are currently developing a SCSI target system with T10-PI. We
> Vlad> are using block integrity interface and found a problem that this
> Vlad&g
Hi,
We are currently developing a SCSI target system with T10-PI. We are using
block integrity interface and found a problem that this interface fundamentally
can not pass Oracle T10-PI certification tests. Those tests require to receive
on the initiator side information about which particular
Dr. Greg Wettstein wrote on 12/03/2014 11:42 PM:
> On Dec 3, 8:59pm, Vladislav Bolkhovitin wrote:
> } Subject: Re: [Scst-devel] New qla2x00tgt Driver Question
>
>> Dr. Greg Wettstein wrote on 12/03/2014 12:46 PM:
>>> Secondly, Vlad, we have been running additional test
Dr. Greg Wettstein wrote on 12/03/2014 12:46 PM:
> Secondly, Vlad, we have been running additional testing for the last
> two days and we have logs from the SCST core which I am including
> below which suggests that the SCST core target code excessively stalls
> or mishandles an ABORT while process
No, because it's too new, but you can always get it from the git. Or you
can use stable Emulex driver for 16Gb connectivity. It's not in the
bundle only because of the Emulex policy.
Thanks,
Vlad
On 9/19/2014 23:59, scst.n...@gmail.com wrote:
Does 16Gb qla2x00t included?
发自我的小米手机
Hi All,
I'm glad to announce that SCST 3.0 has just been released. This release includes SCST
core, target drivers iSCSI-SCST for iSCSI, including iSER support (thanks to
Mellanox!), qla2x00t for QLogic Fibre Channel adapters, ib_srpt for InfiniBand SRP,
fcst for FCoE and scst_local for local
Martin K. Petersen, on 06/23/2014 06:58 PM wrote:
"Mike" == Mike Christie writes:
+ unsigned int xfer_len = blk_rq_bytes(scmd->request);
Mike> Can you do bidi and dif/dix?
Nope.
Correction: at the moment.
There is a proposal of READ GATHERED command, which is bidirectional and potentially
Hi All,
I'm glad to announce SCST 3.0 pre-release code freeze in the SCST SVN branch
3.0.x
You can get it by command:
$ svn co https://scst.svn.sourceforge.net/svnroot/scst/branches/3.0.x
It is going to be released after few weeks of testing, if nothing bad found.
SCST is alternative SCSI tar
I'm glad to announce that SCST iSER target driver is available for testing from
the SCST SVN iser branch. You can download it either by command:
$ svn checkout svn://svn.code.sf.net/p/scst/svn/branches/iser iser-scst-branch
or by clicking on "Download Snapshot" button on
http://sourceforge.net/
Hannes Reinecke, on 10/14/2013 11:01 PM wrote:
> And HBAs like lpfc or qla2xxx even have a fast command abort built
> into the firmware, where the firmware will not even wait for a
> command abort to hit the wire but rather just disable the exchange
> internally and return.
Doing so is asking for
Douglas Gilbert, on 09/18/2013 07:07 AM wrote:
> On 13-09-18 03:58 AM, Jack Wang wrote:
>> On 09/18/2013 08:41 AM, Alireza Haghdoost wrote:
>>> Hi
>>>
>>> I am working on a high throughput and low latency application which
>>> does not tolerate block layer overhead to send IO request directly to
>>
I'm glad to announce that SCST support for 16Gb/s FC and FCoE Emulex CNAs is now
available as part of the Emulex OneCore Storage SDK tool set based on the
Emulex SLI-4
API. Support for 16Gb/s Fibre Channel LPe16000 series and FCoE hardware using
target
mode versions of the OneConnect FCoE CNAs is
Ric Wheeler, on 07/03/2013 11:31 AM wrote:
>>> Journals are normally big (128MB or so?) - I don't think that this is
>>> unique to xfs.
>> We're mixing a bunch of concepts here. The filesystems have a lot of
>> different requirements, and atomics are just one small part.
>>
>> Creating a new file
Martin K. Petersen, on 05/28/2013 01:25 PM wrote:
> Vladislav> Linux block layer is purely artificial creature slowly
> Vladislav> reinventing wheel creating more problems, than solving.
>
> On the contrary. I do think we solve a whole bunch of problems.
>
>
> Vladislav> It enforces approach, wh
Martin K. Petersen, on 05/22/2013 09:32 AM wrote:
> Paolo> First of all, I'll note that SG_IO and block-device-specific
> Paolo> ioctls both have their place. My usecase for SG_IO is
> Paolo> virtualization, where I need to pass information from the LUN to
> Paolo> the virtual machine with as much
Christoph Hellwig, on 10/01/2012 04:46 AM wrote:
On Sun, Sep 30, 2012 at 05:58:11AM +, Nicholas A. Bellinger wrote:
From: Nicholas Bellinger
This patch re-adds the ability to optionally run in buffered FILEIO mode
(eg: w/o O_DSYNC) for device backends in order to once again use the
Linux bu
Luben Tuikov wrote:
Is there an open iSCSI Target implementation which
does NOT
issue commands to sub-target devices via the SCSI
mid-layer, but
bypasses it completely?
What do you mean? To call directly low level backstorage
SCSI drivers
queuecommand() routine? What are advantages of
Nicholas A. Bellinger wrote:
On Thu, 2008-02-07 at 12:37 -0800, Luben Tuikov wrote:
Is there an open iSCSI Target implementation which does NOT
issue commands to sub-target devices via the SCSI mid-layer, but
bypasses it completely?
Luben
Hi Luben,
I am guessing you mean futher down the
Nicholas A. Bellinger wrote:
- It has been discussed which iSCSI target implementation should be in
the mainstream Linux kernel. There is no agreement on this subject
yet. The short-term options are as follows:
1) Do not integrate any new iSCSI target implementation in the
mainstream Linux kernel
[EMAIL PROTECTED] wrote:
On Thu, 7 Feb 2008, Vladislav Bolkhovitin wrote:
Bart Van Assche wrote:
- It has been discussed which iSCSI target implementation should be in
the mainstream Linux kernel. There is no agreement on this subject
yet. The short-term options are as follows:
1) Do not
Luben Tuikov wrote:
Is there an open iSCSI Target implementation which does NOT
issue commands to sub-target devices via the SCSI mid-layer, but
bypasses it completely?
What do you mean? To call directly low level backstorage SCSI drivers
queuecommand() routine? What are advantages of it?
Bart Van Assche wrote:
Since the focus of this thread shifted somewhat in the last few
messages, I'll try to summarize what has been discussed so far:
- There was a number of participants who joined this discussion
spontaneously. This suggests that there is considerable interest in
networked stor
James Bottomley wrote:
On Tue, 2008-02-05 at 21:59 +0300, Vladislav Bolkhovitin wrote:
Hmm, how can one write to an mmaped page and don't touch it?
I meant from user space ... the writes are done inside the kernel.
Sure, the mmap() approach agreed to be unpractical, but coul
Jeff Garzik wrote:
iSCSI is way, way too complicated.
I fully agree. From one side, all that complexity is unavoidable for
case of multiple connections per session, but for the regular case of
one connection per session it must be a lot simpler.
Actually, think about those multiple connecti
Erez Zilber wrote:
Bart Van Assche wrote:
As you probably know there is a trend in enterprise computing towards
networked storage. This is illustrated by the emergence during the
past few years of standards like SRP (SCSI RDMA Protocol), iSCSI
(Internet SCSI) and iSER (iSCSI Extensions for RDMA
Jeff Garzik wrote:
Alan Cox wrote:
better. So for example, I personally suspect that ATA-over-ethernet is way
better than some crazy SCSI-over-TCP crap, but I'm biased for simple and
low-level, and against those crazy SCSI people to begin with.
Current ATAoE isn't. It can't support NCQ. A va
Linus Torvalds wrote:
I'd assumed the move was primarily because of the difficulty of getting
correct semantics on a shared filesystem
.. not even shared. It was hard to get correct semantics full stop.
Which is a traditional problem. The thing is, the kernel always has some
internal state,
Linus Torvalds wrote:
So just going by what has happened in the past, I'd assume that iSCSI
would eventually turn into "connecting/authentication in user space" with
"data transfers in kernel space".
This is exactly how iSCSI-SCST (iSCSI target driver for SCST) is
implemented, credits to IET
James Bottomley wrote:
On Mon, 2008-02-04 at 21:38 +0300, Vladislav Bolkhovitin wrote:
James Bottomley wrote:
On Mon, 2008-02-04 at 20:56 +0300, Vladislav Bolkhovitin wrote:
James Bottomley wrote:
On Mon, 2008-02-04 at 20:16 +0300, Vladislav Bolkhovitin wrote:
James Bottomley wrote
James Bottomley wrote:
On Mon, 2008-02-04 at 20:56 +0300, Vladislav Bolkhovitin wrote:
James Bottomley wrote:
On Mon, 2008-02-04 at 20:16 +0300, Vladislav Bolkhovitin wrote:
James Bottomley wrote:
So, James, what is your opinion on the above? Or the overall SCSI target
project
James Bottomley wrote:
On Mon, 2008-02-04 at 20:16 +0300, Vladislav Bolkhovitin wrote:
James Bottomley wrote:
So, James, what is your opinion on the above? Or the overall SCSI target
project simplicity doesn't matter much for you and you think it's fine
to duplicate Linux page ca
James Bottomley wrote:
So, James, what is your opinion on the above? Or the overall SCSI target
project simplicity doesn't matter much for you and you think it's fine
to duplicate Linux page cache in the user space to keep the in-kernel
part of the project as small as possible?
The answers w
Bart Van Assche wrote:
On Feb 4, 2008 1:27 PM, Vladislav Bolkhovitin <[EMAIL PROTECTED]> wrote:
So, James, what is your opinion on the above? Or the overall SCSI target
project simplicity doesn't matter much for you and you think it's fine
to duplicate Linux page cache in t
James Bottomley wrote:
Vladislav Bolkhovitin wrote:
So, James, what is your opinion on the above? Or the overall SCSI target
project simplicity doesn't matter much for you and you think it's fine
to duplicate Linux page cache in the user space to keep the in-kernel
part of the
Vladislav Bolkhovitin wrote:
James Bottomley wrote:
The two target architectures perform essentially identical functions, so
there's only really room for one in the kernel. Right at the moment,
it's STGT. Problems in STGT come from the user<->kernel boundary which
can b
Vladislav Bolkhovitin wrote:
Bart Van Assche wrote:
On Jan 31, 2008 5:25 PM, Joe Landman <[EMAIL PROTECTED]>
wrote:
Vladislav Bolkhovitin wrote:
Actually, I don't know what kind of conclusions it is possible to make
from disktest's results (maybe only how throughput gets b
David Dillow wrote:
On Thu, 2008-01-31 at 18:08 +0100, Bart Van Assche wrote:
If anyone has a suggestion for a better test than dd to compare the
performance of SCSI storage protocols, please let it know.
xdd on /dev/sda, sdb, etc. using -dio to do direct IO seems to work
decently, though it
Bart Van Assche wrote:
On Jan 31, 2008 5:25 PM, Joe Landman <[EMAIL PROTECTED]> wrote:
Vladislav Bolkhovitin wrote:
Actually, I don't know what kind of conclusions it is possible to make
from disktest's results (maybe only how throughput gets bigger or slower
with incr
Bart Van Assche wrote:
On Jan 31, 2008 2:25 PM, Nicholas A. Bellinger <[EMAIL PROTECTED]> wrote:
Since this particular code is located in a non-data path critical
section, the kernel vs. user discussion is a wash. If we are talking
about data path, yes, the relevance of DD tests in kernel desi
FUJITA Tomonori wrote:
On Wed, 30 Jan 2008 09:38:04 +0100
"Bart Van Assche" <[EMAIL PROTECTED]> wrote:
On Jan 30, 2008 12:32 AM, FUJITA Tomonori <[EMAIL PROTECTED]> wrote:
iSER has parameters to limit the maximum size of RDMA (it needs to
repeat RDMA with a poor configuration)?
Please spec
FUJITA Tomonori wrote:
On Tue, 29 Jan 2008 13:31:52 -0800
Roland Dreier <[EMAIL PROTECTED]> wrote:
> . . STGT read SCST read.STGT read
SCST read.
> . . performance performance . performance
performance .
> .
James Bottomley wrote:
The two target architectures perform essentially identical functions, so
there's only really room for one in the kernel. Right at the moment,
it's STGT. Problems in STGT come from the user<->kernel boundary which
can be mitigated in a variety of ways. The fact that the f
Bart Van Assche wrote:
On Jan 24, 2008 8:06 AM, Robin Humble <[EMAIL PROTECTED]> wrote:
On Tue, Jan 22, 2008 at 01:32:08PM +0100, Bart Van Assche wrote:
.
. . STGT read
Robin Humble wrote:
On Thu, Jan 24, 2008 at 02:10:06PM +0300, Vladislav Bolkhovitin wrote:
On Jan 24, 2008 8:06 AM, Robin Humble <[EMAIL PROTECTED]> wrote:
how are write speeds with SCST SRP?
for some kernels and tests tgt writes at >2x the read speed.
There is a fundamental d
Robin Humble wrote:
On Thu, Jan 24, 2008 at 11:36:45AM +0100, Bart Van Assche wrote:
On Jan 24, 2008 8:06 AM, Robin Humble <[EMAIL PROTECTED]> wrote:
On Tue, Jan 22, 2008 at 01:32:08PM +0100, Bart Van Assche wrote:
Bart Van Assche wrote:
On Jan 24, 2008 8:06 AM, Robin Humble <[EMAIL PROTECTED]> wrote:
On Tue, Jan 22, 2008 at 01:32:08PM +0100, Bart Van Assche wrote:
.
. . STGT read
More information about
the design of SCST can be found here:
http://scst.sourceforge.net/doc/scst_pg.html.
My impression is that both the STGT and SCST projects are well
designed, well maintained and have a considerable user base. According
to the SCST maintainer (Vladislav Bolkhovitin), SCST is superior to
Bart Van Assche wrote:
On Jan 22, 2008 12:33 PM, Vladislav Bolkhovitin <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
What are the new SRPT/iSER numbers?
You can find the new performance numbers below. These are all numbers
for reading from the remote buffer cache, no
FUJITA Tomonori wrote:
On Tue, 22 Jan 2008 14:33:13 +0300
Vladislav Bolkhovitin <[EMAIL PROTECTED]> wrote:
FUJITA Tomonori wrote:
The big problem of stgt iSER is disk I/Os (move data between disk and
page cache). We need a proper asynchronous I/O mechanism, however,
Linux doesn
Bart Van Assche wrote:
On Jan 17, 2008 6:45 PM, Pete Wyckoff <[EMAIL PROTECTED]> wrote:
There's nothing particularly stunning here. Suspect Bart has
configuration issues if not even IPoIB will do > 100 MB/s.
By this time I found out that the BIOS of the test systems (Intel
Server Board S500
FUJITA Tomonori wrote:
The big problem of stgt iSER is disk I/Os (move data between disk and
page cache). We need a proper asynchronous I/O mechanism, however,
Linux doesn't provide such and we use a workaround, which incurs large
latency. I guess, we cannot solve this until syslets is merged int
Bart Van Assche wrote:
On Jan 18, 2008 1:08 PM, Vladislav Bolkhovitin <[EMAIL PROTECTED]> wrote:
[ ... ]
So, seems I understood your slides correctly: the more valuable data for
our SCST SRP vs STGT iSER comparison should be on page 26 for 1 command
read (~480MB/s, i.e. ~60% from Bart&#x
Pete Wyckoff wrote:
I have performed a test to compare the performance of SCST and STGT.
Apparently the SCST target implementation performed far better than
the STGT target implementation. This makes me wonder whether this is
due to the design of SCST or whether STGT's performance can be
improved
Erez Zilber wrote:
FUJITA Tomonori wrote:
On Thu, 17 Jan 2008 12:48:28 +0300
Vladislav Bolkhovitin <[EMAIL PROTECTED]> wrote:
FUJITA Tomonori wrote:
On Thu, 17 Jan 2008 10:27:08 +0100
"Bart Van Assche" <[EMAIL PROTECTED]> wrote:
Hello,
I have perfo
Robin Humble wrote:
On Thu, Jan 17, 2008 at 01:34:46PM +0300, Vladislav Bolkhovitin wrote:
Hmm, I can't find which IB hardware did he use and it's declared Gbps
speed. He declared only "Mellanox 4X SDR, switch". What does it mean?
SDR is 10Gbit carrier, at most about
FUJITA Tomonori wrote:
On Thu, 17 Jan 2008 12:48:28 +0300
Vladislav Bolkhovitin <[EMAIL PROTECTED]> wrote:
FUJITA Tomonori wrote:
On Thu, 17 Jan 2008 10:27:08 +0100
"Bart Van Assche" <[EMAIL PROTECTED]> wrote:
Hello,
I have performed a test to compare the perfor
FUJITA Tomonori wrote:
On Thu, 17 Jan 2008 10:27:08 +0100
"Bart Van Assche" <[EMAIL PROTECTED]> wrote:
Hello,
I have performed a test to compare the performance of SCST and STGT.
Apparently the SCST target implementation performed far better than
the STGT target implementation. This makes me
FUJITA Tomonori wrote:
Thus, I believe, that partial user space, partial kernel space approach
for building SCSI targets is the move in the wrong direction, because it
brings practically nothing, but costs a lot.
We have not discussed such topic. FCoE target can be implemented fully
in user sp
FUJITA Tomonori wrote:
What's the general opinion on this? Duplicate code vs. more kernel code?
I can see that you're already starting to clean up the code that you
ported. Does that mean the duplicate code isn't an issue to you? When we
fix bugs in the initiator they're not going to make it into
James Bottomley wrote:
if you specifically set TAS=1 you're giving up the right to know what
caused the command termination. With insufficient information, it's
really unsafe to simply retry, which is why the mid layer just returns
TASK ABORTED as an error. If you set TAS=0 we'll get a check
co
James Bottomley wrote:
I'm not sure your conclusions necessarily follow your data. What was
the reason for the TASK ABORTED (I'd guess QErr settings, right)?
It was my desire/curiosity during tests of SCST (http://scst.sf.net),
when it working with several initiators with different transports
James Bottomley wrote:
I'm not sure your conclusions necessarily follow your data. What was
the reason for the TASK ABORTED (I'd guess QErr settings, right)?
It was my desire/curiosity during tests of SCST (http://scst.sf.net),
when it working with several initiators with different transports
James Bottomley wrote:
On Tue, 2007-11-20 at 19:15 +0300, Vladislav Bolkhovitin wrote:
James Bottomley wrote:
I'm not sure your conclusions necessarily follow your data. What was
the reason for the TASK ABORTED (I'd guess QErr settings, right)?
It was my desire/curiosity durin
James Bottomley wrote:
On Tue, 2007-11-20 at 18:04 +0300, Vladislav Bolkhovitin wrote:
James Bottomley wrote:
And please close this as invalid. FS ordering guarantees in linux
aren't done via ordered tags.
I had a related question. I was working on the attached patch for soe
James Bottomley wrote:
And please close this as invalid. FS ordering guarantees in linux
aren't done via ordered tags.
I had a related question. I was working on the attached patch for soe
other testing (patch made against scsi-rc-fixes, but is not stable so do
not apply), which does the scs
FUJITA Tomonori wrote:
On Tue, 23 Oct 2007 13:47:20 +0530
"Thayumanavar Sachithanantham" <[EMAIL PROTECTED]> wrote:
Hi All,
Does the recent target mode support added for tgt support target mode
for qla chipset (qla24xx series)?
We've been trying:
http://marc.info/?t=11885798674&r=1&w=
Vladislav Bolkhovitin wrote:
Sean Bruno wrote:
What is the expected behavior when volumes on a SAN change size and LUN
ID order?
I've noticed that if a volume changes size, leaves the SAN or changes
target ID it isn't auto-magically picked up by a 2.6.18 based
system(running CentOS
Sean Bruno wrote:
What is the expected behavior when volumes on a SAN change size and LUN
ID order?
I've noticed that if a volume changes size, leaves the SAN or changes
target ID it isn't auto-magically picked up by a 2.6.18 based
system(running CentOS 5).
If a new target appears on the SAN ho
Vladislav Bolkhovitin wrote:
So, if you need in-kernel pass-through I would suggest you to look at
SCST project (http://scst.sf.net), which is currently stable and mature,
although also not fully finished yet. It was historically from the very
beginning designed for full feature in-kernel pass
Robert Jennings wrote:
* Vladislav Bolkhovitin ([EMAIL PROTECTED]) wrote:
Robert Jennings wrote:
What I meant that is that the kernel tgt code (scsi_tgt*) receives
SCSI commands from one lld and send them to another lld instead of
sending them to user space.
Although the approach of
Robert Jennings wrote:
What I meant that is that the kernel tgt code (scsi_tgt*) receives
SCSI commands from one lld and send them to another lld instead of
sending them to user space.
Although the approach of passing SCSI commands from a target LLD to an
initiator one without any significant i
sandip shete wrote:
Hi,
I wish to develop support for QLA 24xx series. If you already have a
partial implementaion of the same, i would like to take it forward.
And if there isn't, i would appreciate if you could give me some
pointers in that direction.
Most probably, the driver by link sent
sandip shete wrote:
Hi,
I am working with the SCST 0.9.4 version on linux-2.6.15 with the
linux-2.6-qla2xxx-target.patch patch applied.
I was using a QLA2312 card on this setup and things were just fine when
i used this system as a Target.
Now I have switched to a qla2432 card and even though i
Vladislav Bolkhovitin wrote:
FUJITA Tomonori wrote:
From: Vladislav Bolkhovitin <[EMAIL PROTECTED]>
Subject: Re: [Stgt-devel] Question for pass-through target design
Date: Mon, 07 May 2007 19:27:23 +0400
FUJITA Tomonori wrote:
From: Vladislav Bolkhovitin <[EMAIL PROTECTED]>
FUJITA Tomonori wrote:
From: Vladislav Bolkhovitin <[EMAIL PROTECTED]>
Subject: Re: [Stgt-devel] Question for pass-through target design
Date: Mon, 07 May 2007 19:27:23 +0400
FUJITA Tomonori wrote:
From: Vladislav Bolkhovitin <[EMAIL PROTECTED]>
Subject: Re: [Stgt-devel] Quest
FUJITA Tomonori wrote:
From: Vladislav Bolkhovitin <[EMAIL PROTECTED]>
Subject: Re: [Stgt-devel] Question for pass-through target design
Date: Mon, 07 May 2007 18:24:44 +0400
FUJITA Tomonori wrote:
It looks like the pass-through target support is currently broken, at
least as I'
FUJITA Tomonori wrote:
It looks like the pass-through target support is currently broken, at
least as I've checked for ibmvstgt, but I think it's a general problem.
I wanted to check my assumptions and get ideas.
Yeah, unfortunately, it works only with the iSCSI target driver (which
runs in use
Henrique de Moraes Holschuh wrote:
On Thu, 22 Mar 2007, Vladislav Bolkhovitin wrote:
Seems, there is another way of doing a bank spin up / spin down: doing
it in two passes. On the first pass START_STOP will be issued with
IMMED=1 on all devices, then on the second pass START_STOP will be
Tejun Heo wrote:
Hello, Douglas.
Douglas Gilbert wrote:
Tejun,
I note at this point that the IMMED bit in the
START STOP UNIT cdb is clear. [The code might
note that as well.] All SCSI disks that I have
seen, implement the IMMED bit and according to
the SAT standard, so should SAT layers like
Jeremy Linton wrote:
> On Monday 09 October 2006 22:58, Eric Moore wrote:
>
>>On Mon, Oct 09, 2006 at 10:15:20PM -0500, Jeremy Linton wrote:
>>
Is there an equivalent in SATA / SAS land? If there is, is there a
well supported PCI-(E/X) board out there that I could play with?
>>>
>>> W
Mike Christie wrote:
Vladislav Bolkhovitin wrote:
Sorry, I can see on stgt page only mail lists archive and not from
start (from Aug 22). Mike, can I see stgt code and some design
description, please? You can send it directly on my e-mail address, if
necessary.
goto the svn page for the
Dave C Boutcher wrote:
On Wed, Sep 07, 2005 at 12:49:32PM +0200, Christoph Hellwig wrote:
On Tue, Sep 06, 2005 at 04:28:01PM -0500, Dave C Boutcher wrote:
This device driver provides the SCSI target side of the "virtual
SCSI" on IBM Power5 systems. The initiator side has been in mainline
for
Bryan Henderson wrote:
You want to *use* the kernel pagecache as much as you can.
No, I really don't. Not always. I can think of only 2 reasons to
maximize my use of the kernel pagecache: 1) saves me duplicating code; 2)
allows me to share resources (memory and disk bandwidth come to mind) wit
Please, forgive me my ignorance, it looks like something was happened
"behind the scene" (linux-scsi list), and I missed it. Is support for
SCSI targets started to be added in Linux? I mean "SCSI targets" as the
ability to export local devices on a SCSI bus. If so, please consider
proposed SCSI
93 matches
Mail list logo
