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
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
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
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/
Vlad
> boris
>
>> -Original Message-
>> From: Matthew Wilcox [mailto:wi...@linux.intel.com]
>> Sent: Thursday, September 26, 2013 1:56 PM
>> To: Zuckerman, Boris
>> Cc: Vladislav Bolkhovitin; rob.gitt...@linux.intel.com;
>> linux-p...@list
Hi Rob,
Rob Gittins, on 09/23/2013 03:51 PM wrote:
> On Fri, 2013-09-06 at 22:12 -0700, Vladislav Bolkhovitin wrote:
>> Rob Gittins, on 09/04/2013 02:54 PM wrote:
>>> Non-volatile DIMMs have started to become available. A NVDIMMs is a
>>> DIMM that does not lose data
Rob Gittins, on 09/04/2013 02:54 PM wrote:
> Non-volatile DIMMs have started to become available. A NVDIMMs is a
> DIMM that does not lose data across power interruptions. Some of the
> NVDIMMs act like memory, while others are more like a block device
> on the memory bus. Application uses vary
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
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
Hello,
I keep getting on each reboot of my kernel 3.9.1 debug system:
[ 42.037225] [ cut here ]
[ 42.037237] WARNING: at lib/dma-debug.c:937 check_unmap+0x45f/0x8b0()
[ 42.037240] Hardware name: PowerEdge R710
[ 42.037243] ioatdma :00:16.0: DMA-API: device driv
Andreas Steinmetz, on 01/16/2013 08:19 PM wrote:
Thus, lio (http://www.linux-iscsi.org/) seemed to be the politically and
technically favoured solution.
[...]
The fun part of it was that I finally ended up using SCST - which was
refrained from kernel inclusion for technical reasons beyond my
SCST version 2.2.1 has just been released. This release includes SCST core, target
drivers iSCSI-SCST (iSCSI), qla2x00t (QLogic Fibre Channel), ib_srpt (InfiniBand
SRP) and scst_local (local loopback-like access) as well as SCST management
utility scstadmin.
SCST allows creation of sophisticat
Nico Williams, on 11/26/2012 03:05 PM wrote:
Vlad,
You keep saying that programmers don't understand "barriers". You've
provided no evidence of this. Meanwhile memory barriers are generally
well understood, and every programmer I know understands that a
"barrier" is a synchronization primitive
Vladislav Bolkhovitin, on 11/17/2012 12:02 AM wrote:
The easiest way to implement this fsync would involve three things:
1. Schedule writes for all dirty pages in the fs cache that belong to
the affected file, wait for the device to report success, issue a cache
flush to the device (or request
Chris Friesen, on 11/15/2012 05:35 PM wrote:
The easiest way to implement this fsync would involve three things:
1. Schedule writes for all dirty pages in the fs cache that belong to
the affected file, wait for the device to report success, issue a cache
flush to the device (or request ordering
David Lang, on 11/15/2012 07:07 AM wrote:
There's no such thing as "barrier". It is fully artificial abstraction. After
all, at the bottom of your stack, you will have to translate it either to cache
flush, or commands order enforcement, or both.
When people talk about barriers, they are talkin
杨苏立 Yang Su Li, on 11/15/2012 11:14 AM wrote:
1. fsync actually does two things at the same time: ordering writes (in a
barrier-like manner), and forcing cached writes to disk. This makes it very
difficult to implement fsync efficiently.
Exactly!
However, logically they are two distinctive fu
Nico Williams, on 11/13/2012 02:13 PM wrote:
declaring groups of internally-unordered writes where the groups are
ordered with respect to each other... is practically the same as
barriers.
Which barriers? Barriers meaning cache flush or barriers meaning commands order,
or barriers meaning bot
Alan Cox, on 11/13/2012 12:40 PM wrote:
Barriers are pretty much universal as you need them for power off !
I'm afraid, no storage (drives, if you like this term more) at the moment
supports
barriers and, as far as I know the storage history, has never supported.
The ATA cache flush is a wr
杨苏立 Yang Su Li, on 11/10/2012 11:25 PM wrote:
SATA's Native Command
Queuing (NCQ) is not equivalent; this allows the drive to reorder
requests (in particular read requests) so they can be serviced more
efficiently, but it does *not* allow the OS to specify a partial,
relative ordering of reques
Richard Hipp, on 11/02/2012 08:24 AM wrote:
SQLite cares. SQLite is an in-process, transaction, zero-configuration
database that is estimated to be used by over 1 million distinct
applications and to be have over 2 billion deployments. SQLite uses
ordinary disk files in ordinary directories, of
Alan Cox, on 11/02/2012 08:33 AM wrote:
b) most drives will internally re-order requests anyway
They will but only as permitted by the commands queued, so you have some
control depending upon the interface capabilities.
c) cheap drives won't support barriers
Barriers are pretty muc
Howard Chu, on 11/01/2012 08:38 PM wrote:
Alan Cox wrote:
How about that recently preliminary infrastructure to send ORDERED commands
instead of queue draining was deleted from the kernel, because "there's no
difference where to drain the queue, on the kernel or the storage side"?
Send patche
Alan Cox, on 11/01/2012 05:24 PM wrote:
How about that recently preliminary infrastructure to send ORDERED commands
instead of queue draining was deleted from the kernel, because "there's no
difference where to drain the queue, on the kernel or the storage side"?
Send patches.
OK, then we ha
Alan Cox, on 10/31/2012 05:54 AM wrote:
I don't want to flame on this topic, but you are not right here. As far as I can
see, a big chunk of Linux storage and file system developers are/were employed
by
the "gold-plated storage" manufacturers, starting from FusionIO, SGI and Oracle.
You know,
Theodore Ts'o, on 10/27/2012 12:44 AM wrote:
On Fri, Oct 26, 2012 at 09:54:53PM -0400, Vladislav Bolkhovitin wrote:
What different in our positions is that you are considering storage
as something you can connect to your desktop, while in my view
storage is something, which stores dat
Theodore Ts'o, on 10/25/2012 09:50 AM wrote:
Yeah I don't buy that. One, flash is still too expensive. Two,
the capital costs to build enough Silicon foundries to replace the
current production volume of HDD's is way too expensive for any
company to afford (the cloud providers are buying
Theodore Ts'o, on 10/25/2012 01:14 AM wrote:
On Tue, Oct 23, 2012 at 03:53:11PM -0400, Vladislav Bolkhovitin wrote:
Yes, SCSI has full support for ordered/simple commands designed
exactly for that task: to have steady flow of commands even in case
when some of them are ordered.
SCSI
Nico Williams, on 10/24/2012 05:17 PM wrote:
Yes, SCSI has full support for ordered/simple commands designed exactly for
that task: [...]
[...]
But historically for some reason Linux storage developers were stuck with
"barriers" concept, which is obviously not the same as ORDERED commands,
hen
杨苏立 Yang Su Li, on 10/11/2012 12:32 PM wrote:
I am not quite whether I should ask this question here, but in terms
of light weight barrier/fsync, could anyone tell me why the device
driver / OS provide the barrier interface other than some other
abstractions anyway? I am sorry if this sounds like
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
Tomasz Chmielewski wrote:
I have a 1.2 TB (of which 750 GB is used) filesystem which holds
almost 200 millions of files.
1.2 TB doesn't make this filesystem that big, but 200 millions of files
is a decent number.
Most of the files are hardlinked multiple times, some of them are
hardlinked tho
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
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
I've just got it while running "dbench 200" over a XFS mounted
partition. Kernel is 2.6.23. See the attachment.
Regards,
Vlad
Dec 13 16:17:20 tst kernel: [0.00] Linux version 2.6.23-dbg ([EMAIL
PROTECTED]) (gcc version 4.1.1 20070105 (Red Hat 4.1.1-51)) #17 SMP PREEMPT Thu
Oct 25 22:19
Hello,
I apologize if it's already reported, but quick search in LKML archive
didn't find anything like that.
After some dbench runs on ext3 partition, mounted on /mnt, then quickly
umount /mnt, lockdep reported possible circular locking dependency
detected. See attach for the complete messa
Hello,
I've recently bought Realtek RTL8169S-32 chip based Gigabit Ethernet card:
# lspci -vv
Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit
Ethernet (rev 10)
Subsystem: Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit
Ethernet
Control: I/O+ Mem+ BusMaste
Philipp Matthias Hahn wrote:
I would also suggest one more feature: support for block level
de-duplication. I mean:
...
That would be very usable feature, which in most cases would allow to
shrink occupied disk space on 50-90%.
Have you references for this number?
In my experience one gets
[EMAIL PROTECTED] wrote:
> 3. De-de-duplicate blocks on disk, i.e. copy them on write
> > I suppose that de-duplication itself would be done by some user
space
> process that would scan files, determine blocks with the same data and
> then de-duplicate them by using syscall or IOCTL (2).
> > Th
Chris Mason wrote:
On Tue, Jun 19, 2007 at 10:11:13AM +0100, Pádraig Brady wrote:
Vladislav Bolkhovitin wrote:
I would also suggest one more feature: support for block level
de-duplication. I mean:
1. Ability for Btrfs to have blocks in several files to point to the
same block on disk
2
Pádraig Brady wrote:
Vladislav Bolkhovitin wrote:
I would also suggest one more feature: support for block level
de-duplication. I mean:
1. Ability for Btrfs to have blocks in several files to point to the
same block on disk
2. Support for new syscall or IOCTL to de-duplicate as a single
Chris Mason wrote:
Hello everyone,
After the last FS summit, I started working on a new filesystem that
maintains checksums of all file data and metadata. Many thanks to Zach
Brown for his ideas, and to Dave Chinner for his help on
benchmarking analysis.
The basic list of features looks like
Jeff V. Merkey wrote:
> Vladislav Bolkhovitin wrote:
>
>
>>Jeff V. Merkey wrote:
>>
>>
>>
>>>I have noticed that scsi_do_req has apparently been obsoleted in 2.6.18
>>>and above. Is scst and target support for FC-AL going to
>>>re
Jeff V. Merkey wrote:
> I have noticed that scsi_do_req has apparently been obsoleted in 2.6.18
> and above. Is scst and target support for FC-AL going to
> remain supported and/or merged at some point? If so, what is planned
> for scst support for later kernels?
Jeff, I don't know why you as
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
Adrian Bunk wrote:
On Wed, Nov 10, 2004 at 12:58:47PM +0300, Vladislav Bolkhovitin wrote:
Adrian Bunk wrote:
On Wed, Nov 10, 2004 at 11:11:51AM +0300, Vladislav Bolkhovitin wrote:
Moore, Eric Dean wrote:
We need to hold off on this change. Yes, there are
customers of LSI Logic using mptstm.c
Adrian Bunk wrote:
On Wed, Nov 10, 2004 at 12:58:47PM +0300, Vladislav Bolkhovitin wrote:
Adrian Bunk wrote:
On Wed, Nov 10, 2004 at 11:11:51AM +0300, Vladislav Bolkhovitin wrote:
Moore, Eric Dean wrote:
We need to hold off on this change. Yes, there are
customers of LSI Logic using mptstm.c
Check SCSI target mid-level (SCST) with Qlogic target driver on
http://scst.sourceforge.net.
Best regards,
Vlad
Nauman wrote:
hello all the gurus out there,
i have written simple Target for SCSI device. its in very early stage.
I started to handle simple commands from the INITIATOR like INQUIRY,
82 matches
Mail list logo
