On Wed, 2005-03-02 at 13:20, Bryan Henderson wrote:
> >u are talking about application aware caching/prefetching stuff. but i
> >prefer to modifying kernel page cache a little bit while make use of
> >most of the code there.
>
> That's a powerful argument for using the page cache, and further, for
>Bryan Henderson wrote:
>>>You want to *use* the kernel pagecache as much as you can.
>>
>>
>> No, I really don't. Not always. I can think of only 2 reasons to
>> maximize my use of the kernel pagecache: 1) saves me duplicating code;
2)
>> allows me to share resources (memory and disk bandwi
>except that in iscsi a big chunk of the access patterns are *external*;
>eg the real smarts are on that other machine on the network, not in the
>iscsi server.
We strayed a little from the topic; I don't claim that a private
user-space cache is better than the page cache for an ISCSI server. M
>u are talking about application aware caching/prefetching stuff. but i
>prefer to modifying kernel page cache a little bit while make use of
>most of the code there.
That's a powerful argument for using the page cache, and further, for
using it from within the kernel. I once started a project t
Bryan Henderson wrote:
You want to *use* the kernel pagecache as much as you can.
No, I really don't. Not always. I can think of only 2 reasons to
maximize my use of the kernel pagecache: 1) saves me duplicating code; 2)
allows me to share resources (memory and disk bandwidth come to mind) wit
On Wed, 2005-03-02 at 14:04 +0900, FUJITA Tomonori wrote:
> From: FUJITA Tomonori <[EMAIL PROTECTED]>
> Subject: [Iscsitarget-devel] Re: [ANNOUNCE] iSCSI enterprise target software
> Date: Tue, 01 Mar 2005 18:35:49 +0900
>
> > The last reason is that user-space cost lik
From: FUJITA Tomonori <[EMAIL PROTECTED]>
Subject: [Iscsitarget-devel] Re: [ANNOUNCE] iSCSI enterprise target software
Date: Tue, 01 Mar 2005 18:35:49 +0900
> The last reason is that user-space cost like memory copy. With 1Gbs
> Ethernet, is is not critical. However, with 10G, it is
From: Bryan Henderson <[EMAIL PROTECTED]>
Subject: Re: [ANNOUNCE] iSCSI enterprise target software
Date: Tue, 1 Mar 2005 13:04:58 -0800
> >it is hard to beat linux kernel [page] cache performance though.
>
> It's quite easy to beat it for particular applications.
On Tue, Mar 01, 2005 at 09:38:34PM +0100, Andi Kleen wrote:
> Arjan van de Ven <[EMAIL PROTECTED]> writes:
> >
> > You want to *use* the kernel pagecache as much as you can. You do so by
> > using mmap and such, and msync to force content to disk. That uses the
>
> Last time I checked you couldn't
On Tue, 2005-03-01 at 16:04, Bryan Henderson wrote:
> >it is hard to beat linux kernel [page] cache performance though.
>
> It's quite easy to beat it for particular applications. You can use
> special knowledge about the workload to drop pages that won't be accessed
> soon in favor of pages th
On Tue, 2005-03-01 at 13:04 -0800, Bryan Henderson wrote:
> >it is hard to beat linux kernel [page] cache performance though.
>
> It's quite easy to beat it for particular applications. You can use
> special knowledge about the workload to drop pages that won't be accessed
> soon in favor of pa
>it is hard to beat linux kernel [page] cache performance though.
It's quite easy to beat it for particular applications. You can use
special knowledge about the workload to drop pages that won't be accessed
soon in favor of pages that will, not clean a page that's just going to
get discarded
On Tue, 2005-03-01 at 12:53 -0800, Bryan Henderson wrote:
> >You want to *use* the kernel pagecache as much as you can.
>
> No, I really don't. Not always. I can think of only 2 reasons to
> maximize my use of the kernel pagecache: 1) saves me duplicating code; 2)
> allows me to share resource
>You want to *use* the kernel pagecache as much as you can.
No, I really don't. Not always. I can think of only 2 reasons to
maximize my use of the kernel pagecache: 1) saves me duplicating code; 2)
allows me to share resources (memory and disk bandwidth come to mind) with
others in the same
On Tue, 2005-03-01 at 15:38, Andi Kleen wrote:
> Arjan van de Ven <[EMAIL PROTECTED]> writes:
> >
> > You want to *use* the kernel pagecache as much as you can. You do so by
> > using mmap and such, and msync to force content to disk. That uses the
>
> Last time I checked you couldn't mmap block d
Arjan van de Ven <[EMAIL PROTECTED]> writes:
>
> You want to *use* the kernel pagecache as much as you can. You do so by
> using mmap and such, and msync to force content to disk. That uses the
Last time I checked you couldn't mmap block devices. Has this changed
now? Could be a problem for an iS
On Tue, 2005-03-01 at 14:01, Vikas Aggarwal wrote:
> And If future IET be visioned as an Enterprise Class Array(Multiple
> Host-Side Adapters ie., FAs + Multiple Device Side Adapters ie., DAs),
> should better be in direct control of all the system-resources without
> being pushed out the kernel.
On Tue, 2005-03-01 at 14:01, Jeff Garzik wrote:
> Ming Zhang wrote:
> > On Tue, 2005-03-01 at 13:37, Arjan van de Ven wrote:
> >
> >>On Tue, 2005-03-01 at 10:24 -0800, Bryan Henderson wrote:
> >>
> >>>One thing that's implicit in your reasons for wanting to be in the kernel
> >>>is that you've ch
Ming Zhang wrote:
On Tue, 2005-03-01 at 13:37, Arjan van de Ven wrote:
On Tue, 2005-03-01 at 10:24 -0800, Bryan Henderson wrote:
One thing that's implicit in your reasons for wanting to be in the kernel
is that you've chosen to exploit the kernel's page cache. As a user of
the page cache, you ha
On Tue, 2005-03-01 at 13:37, Arjan van de Ven wrote:
> On Tue, 2005-03-01 at 10:24 -0800, Bryan Henderson wrote:
> > One thing that's implicit in your reasons for wanting to be in the kernel
> > is that you've chosen to exploit the kernel's page cache. As a user of
> > the page cache, you have m
On Tue, 2005-03-01 at 10:24 -0800, Bryan Henderson wrote:
> One thing that's implicit in your reasons for wanting to be in the kernel
> is that you've chosen to exploit the kernel's page cache. As a user of
> the page cache, you have more control from inside the kernel than from
> user space.
One thing that's implicit in your reasons for wanting to be in the kernel
is that you've chosen to exploit the kernel's page cache. As a user of
the page cache, you have more control from inside the kernel than from
user space. The page cache was designed to be fundamentally invisible to
user
From: Arjan van de Ven <[EMAIL PROTECTED]>
Subject: Re: [Iscsitarget-devel] Re: [ANNOUNCE] iSCSI enterprise target software
Date: Tue, 01 Mar 2005 11:46:32 +0100
> note that on 32 bit servers the kernel side needs to do kmap() on the
> pages anyway, and that a kmap/kunmap series
On Tue, 2005-03-01 at 11:48 +0100, Libor Vanek wrote:
> >
> I don't know in detail what are you talking about (if whole disk must
> fit address space) but please consider we're speaking about TBs (10-20
> TB RAID is quite cheap nowadays with 400 GB SATA disks).
so? if you need one map/unmap per
Arjan van de Ven wrote:
On Tue, 2005-03-01 at 19:22 +0900, FUJITA Tomonori wrote:
From: Arjan van de Ven <[EMAIL PROTECTED]>
Subject: [Iscsitarget-devel] Re: [ANNOUNCE] iSCSI enterprise target software
Date: Tue, 01 Mar 2005 10:46:03 +0100
fsync or msync() ? I would imagine the
On Tue, 2005-03-01 at 11:33 +0100, Arjan van de Ven wrote:
> On Tue, 2005-03-01 at 19:22 +0900, FUJITA Tomonori wrote:
> > From: Arjan van de Ven <[EMAIL PROTECTED]>
> > Subject: [Iscsitarget-devel] Re: [ANNOUNCE] iSCSI enterprise target software
> > Date: Tue,
On Tue, 2005-03-01 at 19:22 +0900, FUJITA Tomonori wrote:
> From: Arjan van de Ven <[EMAIL PROTECTED]>
> Subject: [Iscsitarget-devel] Re: [ANNOUNCE] iSCSI enterprise target software
> Date: Tue, 01 Mar 2005 10:46:03 +0100
>
> > fsync or msync() ? I would imagine the target
From: Arjan van de Ven <[EMAIL PROTECTED]>
Subject: [Iscsitarget-devel] Re: [ANNOUNCE] iSCSI enterprise target software
Date: Tue, 01 Mar 2005 10:46:03 +0100
> fsync or msync() ? I would imagine the target mmaping it's backend in
> userspace and using msync() to kick off IO. At
On Tue, 2005-03-01 at 18:35 +0900, FUJITA Tomonori wrote:
> From: Arjan van de Ven <[EMAIL PROTECTED]>
> Subject: Re: [ANNOUNCE] iSCSI enterprise target software
> Date: Tue, 01 Mar 2005 09:40:38 +0100
>
> > > Could you please review the code? Any comments ar
From: Arjan van de Ven <[EMAIL PROTECTED]>
Subject: Re: [ANNOUNCE] iSCSI enterprise target software
Date: Tue, 01 Mar 2005 09:40:38 +0100
> > Could you please review the code? Any comments are greatly
> > appreciated.
> > -
>
> can you explain why the target has to
On Tue, 2005-03-01 at 16:19 +0900, FUJITA Tomonori wrote:
> The user-space daemon handles authentication and the kernel threads
> take care of network and disk I/O requests from initiators by using
> the VFS interface. The kernel-space code is not intrusive. It doesn't
> touch other parts of the k
Hi,
I would like to announce the iSCSI enterprise target (IET) software,
which is open-source software to build iSCSI storage systems. It can
provide disk volumes to iSCSI initiators by using any kinds of files
(regular files, block devices, virtual block devices like RAID and
LVM, etc). The proje
32 matches
Mail list logo
