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
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, 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 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
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 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 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, 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
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
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 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
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 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
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
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 project as small
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 k
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
> pa
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 variet
[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 Fri, 2008-02-01 at 14:25 +0100, Bart Van Assche wrote:
> 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 pag
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 (htt
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
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
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
> whi
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
> wai
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
infor
On Thu, 2008-01-31 at 18:40 +0100, Bart Van Assche wrote:
> On Jan 31, 2008 6:14 PM, Nicholas A. Bellinger <[EMAIL PROTECTED]> wrote:
> > Also, with STGT being a pretty new design which has not undergone alot
> > of optimization, perhaps profiling both pieces of code against similar
> > tests would
On Jan 31, 2008 6:14 PM, Nicholas A. Bellinger <[EMAIL PROTECTED]> wrote:
> Also, with STGT being a pretty new design which has not undergone alot
> of optimization, perhaps profiling both pieces of code against similar
> tests would give us a better idea of where userspace bottlenecks reside.
> Al
On Thu, 2008-01-31 at 18:50 +0300, Vladislav Bolkhovitin wrote:
> 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. I
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
Hi Bart,
On Thu, 2008-01-31 at 15:34 +0100, 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 d
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 designs are
> suspect :p.
Greetings all,
On Wed, 2008-01-30 at 19:56 +0900, 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
On Jan 30, 2008 2:54 PM, FUJITA Tomonori <[EMAIL PROTECTED]> wrote:
> On Wed, 30 Jan 2008 14:10:47 +0100
> "Bart Van Assche" <[EMAIL PROTECTED]> wrote:
>
> > On Jan 30, 2008 11:56 AM, FUJITA Tomonori <[EMAIL PROTECTED]> wrote:
> > >
> > > Sorry, I can't say. I don't know much about iSER. But seems
1 - 100 of 116 matches
Mail list logo
