[Stgt-devel] User-mode iSER

[FUJITA Tomonori]

From: "Dan Bar Dov" <danb at voltaire.com>
Subject: Re: [Stgt-devel] User-mode iSER
Date: Sun, 6 Aug 2006 10:59:36 +0300

>  
> 
> > -----Original Message-----
> > From: stgt-devel-bounces at lists.berlios.de 
> > [mailto:stgt-devel-bounces at lists.berlios.de] On Behalf Of 
> > FUJITA Tomonori
> > Sent: Thursday, August 03, 2006 6:20 PM
> > To: Dan Bar Dov
> > Cc: mingz at ele.uri.edu; fujita.tomonori at lab.ntt.co.jp; 
> > stgt-devel at lists.berlios.de; tom at opengridcomputing.com
> > Subject: Re: [Stgt-devel] User-mode iSER
> > 
> > From: "Dan Bar Dov" <danb at voltaire.com>
> > Subject: Re: [Stgt-devel] User-mode iSER
> > Date: Thu, 3 Aug 2006 11:34:33 +0300
> > 
> > >  
> > > 
> > > > -----Original Message-----
> > > > From: stgt-devel-bounces at lists.berlios.de 
> > > > [mailto:stgt-devel-bounces at lists.berlios.de] On Behalf Of 
> > Ming Zhang
> > > > Sent: Wednesday, August 02, 2006 5:20 PM
> > > > To: Tom Tucker
> > > > Cc: FUJITA Tomonori; stgt-devel at lists.berlios.de
> > > > Subject: Re: [Stgt-devel] User-mode iSER
> > > > 
> > > > On Wed, 2006-08-02 at 09:01 -0500, Tom Tucker wrote:
> > > > > [...snip...]
> > > > > > > 
> > > > > > > I think this is the area where we will need to get 
> > > > fancy if we want
> > > > > > > higher performance. To avoid the copy, we would have to 
> > > > migrate to
> > > > > > > netchannels (if they every happen) or implement our own 
> > > > simple tear-away
> > > > > > > buffer scheme on top of a socket. I think this is 
> > > > phase-ii, however. 
> > > > > > 
> > > > > > ok, otherwise copy to user space and copy back to kernel 
> > > > for disk = low
> > > > > > performance. yes, direct io can be used here, but then u 
> > > > lose whole
> > > > > > cache benefits.
> > > > > 
> > > > > Can you elaborate on the loss of "whole cache benefits". 
> > > > 
> > > > if you use a Linux box as a storage server, it will be 
> > desired to use
> > > > page cache as storage cache. though this will bring data integrity
> > > > issues, but so many people still want to have it for specific
> > > > applications.
> > > > 
> > > 
> > > I don't think page cache as storage cache makes sense. If you look
> > > at the networked storage, you have caching on the initiator 
> > (client) side
> > > and you have caching on the target (storage server) side. Storage
> > > servers usually have write-behind cache, and the better ones, have
> > > it battery backed up for data integrity's sake. Storage 
> > admins know to
> > > shutd down write behind caching if it is not backed up.
> > 
> > Modern operating systems and applications (like file systems) does not
> > need help from battery-backed memory to enjoy write-behind cache on
> > SAN target devices for better performance without data corruption
> > risks. So page cache is always useful.
> 
> Since we are working on the SAN target, my point is we need to know if
> this serving target is write-behind or not. If our code relies on page cache, 
> it can not operate in any mode except write behind, however, this is
> an implicit write behind. We could provide a faster response with an explicit 
> write behind.

Sorry, I'm not sure what you mean. What does 'an implicit write
behind' mean?