On Feb 20, 2008 8:34 AM, Erez Zilber <[EMAIL PROTECTED]> wrote:
> Bart Van Assche wrote:
> > Or: data sent during the first burst is not transferred via one-sided
> > remote memory reads or writes but via two-sided send/receive
> > operations. At least on my setup, these operations are as fast as
>
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.
>>
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 R
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. wi
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
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
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
t
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
--- 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
--- 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
> S
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 mainline,
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
> >>byp
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:
> >>
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
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
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.
[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 inte
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, 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
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-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo inf
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
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
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 b
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
elaborate
> Sorry, but I'm afraid you got this wrong. When the iSER transport is
> used instead of TCP, all data is sent via RDMA, including unsolicited
> data. If you have look at the iSER implementation in the Linux kernel
> (source files under drivers/infiniband/ulp/iser), you will see that
> all dat
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 d
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 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 yo
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 -> netwo
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 PROTECTE
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 mul
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
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 cr
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 t
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
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 connect
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
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 th
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, thin
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
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'
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:
Cc:
Andrew Morton
<[EMAIL PROTECTED]>, Alan
Cox <[EMAIL PROTECTED]>, Bart
Van Assche
<[EMAIL PROTECTED]>, FUJITA
Tomonori
<[EMAIL PROTECTED]>,
James Bottomley
<[EMAIL PROTECTED]>, ...
Subject:
Re: Int
On Tue, 5 Feb 2008, Bart Van Assche wrote:
>
> Results that I did not expect:
> * A block transfer size of 1 MB is not enough to measure the maximal
> throughput. The maximal throughput is only reached at much higher
> block sizes (about 10 MB for SCST + SRP and about 100 MB for STGT +
> iSER).
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
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 migh
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 combinatio
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 differen
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 a
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,
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 da
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?
> >>> E
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 havin
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
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
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 m
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
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
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 work
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
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, the
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 biased for simple and
> >> low-level, and against those crazy SCSI people to
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 user
On Mon, 2008-02-04 at 16:24 -0800, 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.
>
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, 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 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'
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 da
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 data[2] -- i.e. the
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 an
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 authoriza
On Mon, 2008-02-04 at 15:12 -0800, Nicholas A. Bellinger wrote:
> 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 cr
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, an
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 an
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'
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
Linus Torvalds wrote:
So no, performance is not the only reason to move to kernel space. It can
easily be things like needing direct access to internal data queues (for a
iSCSI target, this could be things like barriers or just tagged commands -
yes, you can probably emulate things like that wi
> 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 and IP
would p
On Mon, 2008-02-04 at 13:24 -0800, Linus Torvalds wrote:
>
> 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 s
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
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 t
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
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,
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 talking about scaling TCP for 10
> Gb/sec storage fabrics
On Mon, 2008-02-04 at 11:06 -0800, Nicholas A. Bellinger wrote:
> 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
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 cop
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 wr
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 cop
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 simplicit
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* th
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
> >>projec
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 u
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 spa
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 the user space to keep
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
1 - 100 of 146 matches
Mail list logo
