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)
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
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, where often
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 often uses
Martin K. Petersen, on 06/23/2014 06:58 PM wrote:
Mike == Mike Christie micha...@cs.wisc.edu 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
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
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?
发自我的小米手机
Vladislav
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 processing
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 testing for the last
two days and we
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
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 5
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=11885798674r=1w=2
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 during tests
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
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
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
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
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 Bellingern...@linux-iscsi.org
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
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
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
fiber channel
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
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
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
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
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've checked
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] Question for pass
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]
Subject: Re: [Stgt
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
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
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
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
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
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
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
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
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:
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 performance of SCST and STGT
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 ~900MB/s data rate.
DDR
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 performed a test to compare
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
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's result
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
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
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't provide
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 actual disk reads
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
STGT
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 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:
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 difference
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
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
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 .
.
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 specify
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
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 increasing number of threads
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 bigger or
slower
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
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 the user space to keep
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
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 cache
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 be mitigated in a variety
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
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
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
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
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
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
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 and
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 could you
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
[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
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?
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
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
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
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
Martin K. Petersen wrote on 12/11/2014 07:12 PM:
Vlad == Vladislav Bolkhovitin v...@vlnb.net 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 interface fundamentally can not pass Oracle T10
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 initiator
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
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
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 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
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,
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
86 matches
Mail list logo
