Bart Van Assche wrote:
On Feb 18, 2008 10:43 AM, Erez Zilber [EMAIL PROTECTED] wrote:
If you use a high value for FirstBurstLength, all (or most) of your data
will be sent as unsolicited data-out PDUs. These PDUs don't use the RDMA
engine, so you miss the advantage of IB.
Hello
Bart Van Assche wrote:
On Feb 5, 2008 6:01 PM, Erez Zilber [EMAIL PROTECTED] wrote:
Using such large values for FirstBurstLength will give you poor
performance numbers for WRITE commands (with iSER). FirstBurstLength
means how much data should you send as unsolicited data (i.e. without
On Feb 18, 2008 10:43 AM, Erez Zilber [EMAIL PROTECTED] wrote:
If you use a high value for FirstBurstLength, all (or most) of your data
will be sent as unsolicited data-out PDUs. These PDUs don't use the RDMA
engine, so you miss the advantage of IB.
Hello Erez,
Did you notice the e-mail
On Thu, Feb 7, 2008 at 2:45 PM, Vladislav Bolkhovitin [EMAIL PROTECTED] wrote:
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
Greetings all,
On Tue, 2008-02-12 at 17:05 +0100, Bart Van Assche wrote:
On Feb 6, 2008 1:11 AM, Nicholas A. Bellinger [EMAIL PROTECTED] wrote:
I have always observed the case with LIO SE/iSCSI target mode ...
Hello Nicholas,
Are you sure that the LIO-SE kernel module source code is
On Feb 6, 2008 1:11 AM, Nicholas A. Bellinger [EMAIL PROTECTED] wrote:
I have always observed the case with LIO SE/iSCSI target mode ...
Hello Nicholas,
Are you sure that the LIO-SE kernel module source code is ready for
inclusion in the mainstream Linux kernel ? As you know I tried to test
the
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
[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?
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 stack, which I don't know
On Thu, 2008-02-07 at 14:51 -0800, [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
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
On Fri, 2008-02-08 at 17:36 +0300, Vladislav Bolkhovitin wrote:
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
On Fri, 2008-02-08 at 17:42 +0300, Vladislav Bolkhovitin wrote:
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
On Fri, 8 Feb 2008, Vladislav Bolkhovitin wrote:
2. I think, everybody will agree that Linux iSCSI target should work over
some standard SCSI target framework. Hence the choice gets narrower: SCST
vs STGT. I don't think there's a way for a dedicated iSCSI target (i.e.
PyX/LIO) in the
--- On Fri, 2/8/08, Vladislav Bolkhovitin [EMAIL PROTECTED] 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
--- On Fri, 2/8/08, Nicholas A. Bellinger [EMAIL PROTECTED] 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
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 storage and iSCSI.
- It has
On Thu, 2008-02-07 at 14:13 +0100, 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
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
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
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
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 integrate any new iSCSI target
On Feb 5, 2008 6:50 PM, Jeff Garzik [EMAIL PROTECTED] wrote:
For remotely accessing data, iSCSI+fs is quite simply more overhead than
a networked fs. With iSCSI you are doing
local VFS - local blkdev - network
whereas a networked filesystem is
local VFS - network
There
On Feb 5, 2008 6:01 PM, Erez Zilber [EMAIL PROTECTED] wrote:
Using such large values for FirstBurstLength will give you poor
performance numbers for WRITE commands (with iSER). FirstBurstLength
means how much data should you send as unsolicited data (i.e. without
RDMA). It means that your
Bart Van Assche wrote:
On Feb 5, 2008 6:50 PM, Jeff Garzik [EMAIL PROTECTED] wrote:
For remotely accessing data, iSCSI+fs is quite simply more overhead than
a networked fs. With iSCSI you are doing
local VFS - local blkdev - network
whereas a networked filesystem is
local
On Feb. 06, 2008, 14:16 +0200, Bart Van Assche [EMAIL PROTECTED] wrote:
On Feb 5, 2008 6:01 PM, Erez Zilber [EMAIL PROTECTED] wrote:
Using such large values for FirstBurstLength will give you poor
performance numbers for WRITE commands (with iSER). FirstBurstLength
means how much data should
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
On Feb 4, 2008 11:57 PM, Jeff Garzik [EMAIL PROTECTED] wrote:
Networked block devices are attractive because the concepts and
implementation are more simple than networked filesystems... but usually
you want to run some sort of filesystem on top. At that point you might
as well run NFS or
On Mon, Feb 04, 2008 at 05:57:47PM -0500, Jeff Garzik wrote:
iSCSI and NBD were passe ideas at birth. :)
Networked block devices are attractive because the concepts and
implementation are more simple than networked filesystems... but usually
you want to run some sort of filesystem on top.
On Tue, 05 Feb 2008 08:14:01 +0100
Tomasz Chmielewski [EMAIL PROTECTED] wrote:
James Bottomley schrieb:
These are both features being independently worked on, are they not?
Even if they weren't, the combination of the size of SCST in kernel plus
the problem of having to find a migration
On Tue, 05 Feb 2008 05:43:10 +0100
Matteo Tescione [EMAIL PROTECTED] wrote:
Hi all,
And sorry for intrusion, i am not a developer but i work everyday with iscsi
and i found it fantastic.
Altough Aoe, Fcoe and so on could be better, we have to look in real world
implementations what is needed
On Mon, 4 Feb 2008 20:07:01 -0600
Chris Weiss [EMAIL PROTECTED] wrote:
On Feb 4, 2008 11:30 AM, Douglas Gilbert [EMAIL PROTECTED] 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
FUJITA Tomonori schrieb:
On Tue, 05 Feb 2008 08:14:01 +0100
Tomasz Chmielewski [EMAIL PROTECTED] wrote:
James Bottomley schrieb:
These are both features being independently worked on, are they not?
Even if they weren't, the combination of the size of SCST in kernel plus
the problem of having
On Tue, 2008-02-05 at 17:07 +0100, Tomasz Chmielewski wrote:
FUJITA Tomonori schrieb:
On Tue, 05 Feb 2008 08:14:01 +0100
Tomasz Chmielewski [EMAIL PROTECTED] wrote:
James Bottomley schrieb:
These are both features being independently worked on, are they not?
Even if they weren't,
Regarding the performance tests I promised to perform: although until
now I only have been able to run two tests (STGT + iSER versus SCST +
SRP), the results are interesting. I will run the remaining test cases
during the next days.
About the test setup: dd and xdd were used to transfer 2 GB of
On Tue, 05 Feb 2008 17:07:07 +0100
Tomasz Chmielewski [EMAIL PROTECTED] wrote:
FUJITA Tomonori schrieb:
On Tue, 05 Feb 2008 08:14:01 +0100
Tomasz Chmielewski [EMAIL PROTECTED] wrote:
James Bottomley schrieb:
These are both features being independently worked on, are they not?
Even
Bart Van Assche 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 which parameters you are referring to. As you know I
had already
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). Two different
On 5-02-2008 14:38, FUJITA Tomonori [EMAIL PROTECTED] wrote:
On Tue, 05 Feb 2008 08:14:01 +0100
Tomasz Chmielewski [EMAIL PROTECTED] wrote:
James Bottomley schrieb:
These are both features being independently worked on, are they not?
Even if they weren't, the combination of the size of
Bart Van Assche wrote:
On Feb 4, 2008 11:57 PM, Jeff Garzik [EMAIL PROTECTED] wrote:
Networked block devices are attractive because the concepts and
implementation are more simple than networked filesystems... but usually
you want to run some sort of filesystem on top. At that point you might
Olivier Galibert wrote:
On Mon, Feb 04, 2008 at 05:57:47PM -0500, Jeff Garzik wrote:
iSCSI and NBD were passe ideas at birth. :)
Networked block devices are attractive because the concepts and
implementation are more simple than networked filesystems... but usually
you want to run some sort
:
Andrew Morton
[EMAIL PROTECTED], Alan
Cox [EMAIL PROTECTED], Bart
Van Assche
[EMAIL PROTECTED], FUJITA
Tomonori
[EMAIL PROTECTED],
James Bottomley
[EMAIL PROTECTED], ...
Subject:
Re: Integration of SCST in the
mainstream Linux kernel
Date
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
Vladislav Bolkhovitin wrote:
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,
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
elaborate more on this
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
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
On Feb 5, 2008 6:10 PM, Erez Zilber [EMAIL PROTECTED] wrote:
One may claim that STGT should have lower performance than SCST because
its data path is from userspace. However, your results show that for
non-IB transports, they both show the same numbers. Furthermore, with IB
there shouldn't be
On Tue, 2008-02-05 at 22:21 +0300, Vladislav Bolkhovitin wrote:
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
On Tue, 2008-02-05 at 14:12 -0500, Jeff Garzik wrote:
Vladislav Bolkhovitin wrote:
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
On Tue, 2008-02-05 at 22:01 +0300, Vladislav Bolkhovitin wrote:
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
On Tue, 2008-02-05 at 16:48 -0800, Nicholas A. Bellinger wrote:
On Tue, 2008-02-05 at 22:01 +0300, Vladislav Bolkhovitin wrote:
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,
On Tue, 05 Feb 2008 18:09:15 +0100
Matteo Tescione [EMAIL PROTECTED] wrote:
On 5-02-2008 14:38, FUJITA Tomonori [EMAIL PROTECTED] wrote:
On Tue, 05 Feb 2008 08:14:01 +0100
Tomasz Chmielewski [EMAIL PROTECTED] wrote:
James Bottomley schrieb:
These are both features being
On Tue, 2008-02-05 at 16:11 -0800, Nicholas A. Bellinger wrote:
On Tue, 2008-02-05 at 22:21 +0300, Vladislav Bolkhovitin wrote:
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
On Wed, 2008-02-06 at 10:29 +0900, FUJITA Tomonori wrote:
On Tue, 05 Feb 2008 18:09:15 +0100
Matteo Tescione [EMAIL PROTECTED] wrote:
On 5-02-2008 14:38, FUJITA Tomonori [EMAIL PROTECTED] wrote:
On Tue, 05 Feb 2008 08:14:01 +0100
Tomasz Chmielewski [EMAIL PROTECTED] 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 the in-kernel
part of
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
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 in the user space to keep the
On Mon, 2008-02-04 at 19:25 +0300, Vladislav Bolkhovitin wrote:
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
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:
So, James, what
On Mon, 2008-02-04 at 10:29 -0800, Linus Torvalds wrote:
On Mon, 4 Feb 2008, James Bottomley wrote:
The way a user space solution should work is to schedule mmapped I/O
from the backing store and then send this mmapped region off for target
I/O.
mmap'ing may avoid the copy, but the
On Mon, 4 Feb 2008, James Bottomley wrote:
The way a user space solution should work is to schedule mmapped I/O
from the backing store and then send this mmapped region off for target
I/O.
mmap'ing may avoid the copy, but the overhead of a mmap operation is
quite often much *bigger* than
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 simplicity doesn't matter
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 in 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 be mitigated in a variety
On Mon, 2008-02-04 at 15:27 +0300, Vladislav Bolkhovitin 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
On Mon, 2008-02-04 at 14:53 +0100, Bart Van Assche wrote:
Another issue I have to look further into is that dd and xdd report
different results for very large block sizes ( 1 MB).
Be aware that xdd reports 1 MB as 100, not 1048576. Though, it looks
like dd is the same, so that's probably
On Mon, 2008-02-04 at 10:29 -0800, Linus Torvalds wrote:
On Mon, 4 Feb 2008, James Bottomley wrote:
The way a user space solution should work is to schedule mmapped I/O
from the backing store and then send this mmapped region off for target
I/O.
mmap'ing may avoid the copy, but the
On Mon, 2008-02-04 at 11:44 -0800, Linus Torvalds wrote:
On Mon, 4 Feb 2008, Nicholas A. Bellinger wrote:
While this does not have anything to do directly with the kernel vs.
user discussion for target mode storage engine, the scaling and latency
case is easy enough to make if we are
On Mon, 4 Feb 2008, J. Bruce Fields 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
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
On Mon, 2008-02-04 at 17:00 -0600, James Bottomley wrote:
On Mon, 2008-02-04 at 22:43 +, 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
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 variant that did NCQ
On Mon, 2008-02-04 at 22:43 +, 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
On lunedì 4 febbraio 2008, Linus Torvalds wrote:
So from a purely personal standpoint, I'd like to say that I'm not really
interested in iSCSI (and I don't quite know why I've been cc'd on this
whole discussion) and think that other approaches are potentially *much*
better. So for example, I
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 variant that did NCQ
Linus Torvalds wrote:
On Mon, 4 Feb 2008, Jeff Garzik wrote:
Well, speaking as a complete nutter who just finished the bare bones of an
NFSv4 userland server[1]... it depends on your approach.
You definitely are a complete nutter ;)
If the userland server is the _only_ one accessing the
On Mon, 2008-02-04 at 22:43 +, 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
On Mon, 4 Feb 2008, Matt Mackall wrote:
But ATAoE is boring because it's not IP. Which means no routing,
firewalls, tunnels, congestion control, etc.
The thing is, that's often an advantage. Not just for performance.
NBD and iSCSI (for all its hideous growths) can take advantage of these
On Mon, Feb 04, 2008 at 11:44:31AM -0800, Linus Torvalds wrote:
...
Pure user-space solutions work, but tend to eventually be turned into
kernel-space if they are simple enough and really do have throughput and
latency considerations (eg nfsd), and aren't quite complex and crazy
enough to
On Mon, 4 Feb 2008, Jeff Garzik wrote:
For years I have been hoping that someone will invent a simple protocol (w/
strong auth) that can transit ATA and SCSI commands and responses. Heck, it
would be almost trivial if the kernel had a TLS/SSL implementation.
Why would you want
Linus Torvalds wrote:
On Mon, 4 Feb 2008, Matt Mackall wrote:
But ATAoE is boring because it's not IP. Which means no routing,
firewalls, tunnels, congestion control, etc.
The thing is, that's often an advantage. Not just for performance.
NBD and iSCSI (for all its hideous growths) can take
On Mon, 4 Feb 2008, Jeff Garzik wrote:
Both of these are easily handled if the server is 100% in charge of managing
the filesystem _metadata_ and data. That's what I meant by complete control.
i.e. it not ext3 or reiserfs or vfat, its a block device or 1000GB file
managed by a userland
Hi all,
And sorry for intrusion, i am not a developer but i work everyday with iscsi
and i found it fantastic.
Altough Aoe, Fcoe and so on could be better, we have to look in real world
implementations what is needed *now*, and if we look at vmware world,
virtual iron, microsoft clustering etc,
On Tue, 2008-02-05 at 05:43 +0100, Matteo Tescione wrote:
Hi all,
And sorry for intrusion, i am not a developer but i work everyday with iscsi
and i found it fantastic.
Altough Aoe, Fcoe and so on could be better, we have to look in real world
implementations what is needed *now*, and if we
James Bottomley schrieb:
These are both features being independently worked on, are they not?
Even if they weren't, the combination of the size of SCST in kernel plus
the problem of having to find a migration path for the current STGT
users still looks to me to involve the greater amount of
[EMAIL PROTECTED] wrote on Wed, 30 Jan 2008 10:34 -0600:
On Wed, 2008-01-30 at 09:38 +0100, Bart Van Assche 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
On Jan 31, 2008 2:25 PM, Nicholas A. Bellinger [EMAIL PROTECTED] wrote:
The PyX storage engine supports a scatterlist linked list algorithm that
...
Which parts of the PyX source code are licensed under the GPL and
which parts are closed source ? A Google query for PyX + iSCSI showed
On Jan 31, 2008 7:15 PM, Nicholas A. Bellinger [EMAIL PROTECTED] wrote:
I meant small referring to storage on IB fabrics which has usually been
in the research and national lab settings, with some other vendors
offering IB as an alternative storage fabric for those who [w,c]ould not
wait for
On Fri, 2008-02-01 at 09:11 +0100, Bart Van Assche wrote:
On Jan 31, 2008 2:25 PM, Nicholas A. Bellinger [EMAIL PROTECTED] wrote:
The PyX storage engine supports a scatterlist linked list algorithm that
...
Which parts of the PyX source code are licensed under the GPL and
which parts
On Feb 1, 2008 11:39 AM, Nicholas A. Bellinger [EMAIL PROTECTED] wrote:
On Fri, 2008-02-01 at 09:11 +0100, Bart Van Assche wrote:
On Jan 31, 2008 2:25 PM, Nicholas A. Bellinger [EMAIL PROTECTED] wrote:
The PyX storage engine supports a scatterlist linked list algorithm that
...
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
On Fri, 2008-02-01 at 12:04 +0100, Bart Van Assche wrote:
On Feb 1, 2008 11:39 AM, Nicholas A. Bellinger [EMAIL PROTECTED] wrote:
On Fri, 2008-02-01 at 09:11 +0100, Bart Van Assche wrote:
On Jan 31, 2008 2:25 PM, Nicholas A. Bellinger [EMAIL PROTECTED] wrote:
The PyX storage engine
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
On Feb 1, 2008 1:05 PM, Nicholas A. Bellinger [EMAIL PROTECTED] wrote:
All of the kernel and C userspace code is open source and available from
linux-iscsi.org and licensed under the GPL.
I found a statement on a web page that the ERL2 implementation is not
included in the GPL version
1 - 100 of 132 matches
Mail list logo
