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 are greatly > > > appreciated. > > > - > > > > can you explain why the target has to be inside the kernel and can't be > > a pure userspace daemon ? > > o synchronization > > Suppose that an target runs in the user space and an initiator sends > two WRITE commands (A and B) with the simple attribute. > > The target can write A and B simultaneously. Before the target sends > the response of A, A must be committed to disk (that is, some dirty > page cache must be committed). So the target calls fsync(). It commits > A to disk. Moreover, it also commits B to disk unnecessarily. This > really hurts performance.
fsync or msync() ? I would imagine the target mmaping it's backend in userspace and using msync() to kick off IO. At which point it's not that much different from the control you do of the pagecache from inside the kernel... > o disk drive cache > > When the target calls fsync(), dirty page cache is supposed to be > committed to disk. However, the disk drive uses write-back policy, it > is not. The data is still in disk drive cache. There is no system call > to control disk drive cache. So the target (in the user space) cannot > make good use of it. fsync() (and I suppose msync()) nowadays send a "flush cache" command to the physical disk as well. This is new since 2.6.9 or so. > The current code also assumes the disk drive uses write-through > policy. This is because no handy vfs interface for controlling disk > drive cache. I think that there is some room for further improvement > in the Linux kernel for storage systems. that's already present since 2.6.9..... > The last reason is that user-space cost like memory copy. With 1Gbs > Ethernet, is is not critical. However, with 10G, it is critical, I > expect. I've been setting up 10G experimental infrastructure to > evaluate iSCSI performance. if you use the mmap not write/read approach this copy isn't there. - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
