You can subscribe to this list here.
2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(14) |
Jun
(46) |
Jul
(43) |
Aug
(199) |
Sep
(329) |
Oct
(214) |
Nov
(198) |
Dec
(236) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2005 |
Jan
(316) |
Feb
(240) |
Mar
(230) |
Apr
(300) |
May
(339) |
Jun
(301) |
Jul
(284) |
Aug
(213) |
Sep
(197) |
Oct
(150) |
Nov
(216) |
Dec
(287) |
2006 |
Jan
(346) |
Feb
(189) |
Mar
(222) |
Apr
(260) |
May
(100) |
Jun
(184) |
Jul
(229) |
Aug
(102) |
Sep
(82) |
Oct
(216) |
Nov
(389) |
Dec
(466) |
2007 |
Jan
(512) |
Feb
(330) |
Mar
(322) |
Apr
(271) |
May
(301) |
Jun
(251) |
Jul
(302) |
Aug
(168) |
Sep
(134) |
Oct
(132) |
Nov
(223) |
Dec
(75) |
2008 |
Jan
(101) |
Feb
(115) |
Mar
(83) |
Apr
(111) |
May
(91) |
Jun
(180) |
Jul
(101) |
Aug
(75) |
Sep
(178) |
Oct
(104) |
Nov
(159) |
Dec
(131) |
2009 |
Jan
(135) |
Feb
(84) |
Mar
(84) |
Apr
(63) |
May
(44) |
Jun
(25) |
Jul
(68) |
Aug
(95) |
Sep
(183) |
Oct
(118) |
Nov
(61) |
Dec
(156) |
2010 |
Jan
(172) |
Feb
(186) |
Mar
(204) |
Apr
(449) |
May
(52) |
Jun
(136) |
Jul
(35) |
Aug
(19) |
Sep
(93) |
Oct
(89) |
Nov
(62) |
Dec
(29) |
2011 |
Jan
(91) |
Feb
(37) |
Mar
(97) |
Apr
(53) |
May
(50) |
Jun
(50) |
Jul
(44) |
Aug
(26) |
Sep
(52) |
Oct
(42) |
Nov
(28) |
Dec
(63) |
2012 |
Jan
(103) |
Feb
(40) |
Mar
(83) |
Apr
(66) |
May
(54) |
Jun
(35) |
Jul
(13) |
Aug
(2) |
Sep
(27) |
Oct
(47) |
Nov
(13) |
Dec
(17) |
2013 |
Jan
|
Feb
(12) |
Mar
(5) |
Apr
(10) |
May
(21) |
Jun
(4) |
Jul
(15) |
Aug
|
Sep
(37) |
Oct
(3) |
Nov
(1) |
Dec
|
2014 |
Jan
(8) |
Feb
(3) |
Mar
(5) |
Apr
(5) |
May
(6) |
Jun
(18) |
Jul
(7) |
Aug
(8) |
Sep
(5) |
Oct
|
Nov
(3) |
Dec
(2) |
2015 |
Jan
(5) |
Feb
|
Mar
(4) |
Apr
(6) |
May
(15) |
Jun
(14) |
Jul
(4) |
Aug
|
Sep
(1) |
Oct
|
Nov
(2) |
Dec
|
2016 |
Jan
(9) |
Feb
(2) |
Mar
|
Apr
|
May
(1) |
Jun
(1) |
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
(6) |
2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Ming Z. <mi...@el...> - 2004-06-24 12:38:19
|
my 2c. better and more flexible architecture. keep most of the work at user space if possible. ming On Thu, 2004-06-24 at 08:05, ar...@ma... wrote: > Hello list, > > I'm curious why you chose to build your target upon Ardistech's code base, > as UNH's implementation seems to be a bit more advanced feature-wise and > doesn't perform too bad, either. > Did you decide to use the Ardistech target solely because of its support > for generic block devices, which wasn't actually available for UNHs target > until recently (and is still "improvable"), or were there any performance- > or even other considerations as well? > Thanks in advance. > > Regards, > Arne Redlich > > > ------------------------------------------------------- > This SF.Net email sponsored by Black Hat Briefings & Training. > Attend Black Hat Briefings & Training, Las Vegas July 24-29 - > digital self defense, top technical experts, no vendor pitches, > unmatched networking opportunities. Visit www.blackhat.com > _______________________________________________ > Iscsitarget-devel mailing list > Isc...@li... > https://lists.sourceforge.net/lists/listinfo/iscsitarget-devel -- -------------------------------------------------- | Ming Zhang, PhD. Student | Dept. of Electrical & Computer Engineering | College of Engineering | University of Rhode Island | Kingston RI. 02881 | e-mail: mingz at ele.uri.edu | Tel. (401) 874-2293 | Fax. (401) 782-6422 | http://www.ele.uri.edu/~mingz/ -------------------------------------------------- |
From: <ar...@ma...> - 2004-06-24 12:05:24
|
Hello list, I'm curious why you chose to build your target upon Ardistech's code base, as UNH's implementation seems to be a bit more advanced feature-wise and doesn't perform too bad, either. Did you decide to use the Ardistech target solely because of its support for generic block devices, which wasn't actually available for UNHs target until recently (and is still "improvable"), or were there any performance- or even other considerations as well? Thanks in advance. Regards, Arne Redlich |
From: FUJITA T. <to...@ac...> - 2004-06-23 16:37:30
|
Hi, From: joh...@ca... Subject: [Iscsitarget-devel] [unh-iscsi - Open Discussion] ANNOUNCE: Generic SCSI Target Mid-Level Date: Wed, 16 Jun 2004 19:43:25 +0200 > Will this be useful for us? The concept, that is, implementing a generic interface for iSCSI targets is interesting. However, using the SCSI subsystem directly does not make sense. I cite Christoph Hellwing's response on linux-scsi mailing list. -- The code looks pretty neat to me, there's a few issues I'd like to see addresses but that doesn't make sense before the 2.4 support is dropped and there's an actual LLDD for 2.6. But I think for most interesting scenarios in the storage virtualization world your driver is pretty much useless because it wants to dispatch directly to a scsi device and doesn't go through the block layer. So no fancy volume managers/etc there to make interesting storage virtualization boxes. -- I'm totally of the same opinion. An iSCSI target that just runs fast is not good enough for production environments. Rich management features, like Snapshot, which the LVM provides, are essential. Thus, I think that a generic interface for iSCSI targets must work with the block layer or the vfs interface. Bye, |
From: <joh...@ca...> - 2004-06-16 17:43:15
|
Hi! Will this be useful for us? Best regards from/Med v=E4nliga h=E4lsningar fr=E5n Johan Kragsterman http://www.capvert.se ----- Vidarebefordrat av Johan Kragsterman/DominoHotell 2004-06-16 19:= 38 ----- = =20 "SourceForge.ne = =20 t" Till: noreply@sourceforge.n= et =20 <noreply@source Kopia: = =20 forge.net> =C4rende: [unh-iscsi - Open D= iscussion] ANNOUNCE: =20 Generic SCSI Target Mid-Leve= l =20 2004-06-16 = =20 18:44 = =20 = =20 = =20 Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=3D2621175 By: vlnb I would like to announce that the first public release of a generic SCS= I target middle level subsystem for Linux (SCST) is available on http://scst.sf.= net together a patch for for UNH-iSCSI Target 1.5.3 to work over SCST. SCST is designed to provide unified, consistent interface between SCSI target drivers and Linux kernel and simplify target drivers development as muc= h as possible. It has a lot of features, which you can observe on its page, = and I hope that UNH-iSCSI target driver will greatly benefit from them. Interface between SCST and target drivers is based on work, done by InterOperability Lab (IOL) of University of New Hampshier (UNH). Enjoy! Vlad ______________________________________________________________________ You are receiving this email because you elected to monitor this forum.= To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=3D265256 = |
From: FUJITA T. <to...@ac...> - 2004-06-15 15:16:35
|
From: Ming Zhang <mi...@el...> Subject: Re: [Iscsitarget-devel] Write performance Date: Tue, 15 Jun 2004 09:49:28 -0400 > On Mon, 2004-06-14 at 21:42, FUJITA Tomonori wrote: > > Hello, > > > > I've attached the results of sequential write tests. > > > > o Target > > CPU : Xeon 2.8GHz > single or dual? i have a dual box and i can perform some tests later. It's a dual CPU box with Hyper-Threading. So it has 4 processors. However, Ardis doesn't work with a smp box. so I performed the tests with a single CPU kernel. > > Mem : 2GB > > Disk : Maxtor Atlas 10K SCSI (10000 RPM) / LSI Logic 53C103 > I am wondering if u have better storage. :P or u can use a ram disk to > find the upper limit of the code? I have a box with 15,000 RPM SCSI disks. But it wasn't available at that time. Ardis doesn't support ramdisk (tmpfs). So I didn't play with it. I think that an IO mode to keep all data in virtual memory is interesting. The easiest solution is the combination of tmfs and the file IO mode. With slight modifications, the file IO mode works with a regular file. > > This benchmark sequentially writes data 50,000 times with the I/O > > sizes ranging from 2KB to 32 KB. > can we have 64kb and 128kb? Ardis crashed at 32KB. And it seems that there are some bottlenecks at 16KB with the configuration. So I didn't perform the tests over 64KB. |
From: Ming Z. <mi...@el...> - 2004-06-15 13:49:34
|
Thanks a lot for all your work. A great job! On Mon, 2004-06-14 at 21:42, FUJITA Tomonori wrote: > Hello, > > I've attached the results of sequential write tests. > > o Target > CPU : Xeon 2.8GHz single or dual? i have a dual box and i can perform some tests later. > Mem : 2GB > Disk : Maxtor Atlas 10K SCSI (10000 RPM) / LSI Logic 53C103 I am wondering if u have better storage. :P or u can use a ram disk to find the upper limit of the code? > NIC : Intel Pro/1000 MT > Kernel : 2.4.25 > > o Initiator > CPU : Xeon 2.0GHz > Mem : 1GB > NIC : Intel Pro/1000 MT > Kernel : 2.6.4 > > The initiator box runs the Cisco iSCSI driver v4.0.1.1 > > This benchmark sequentially writes data 50,000 times with the I/O > sizes ranging from 2KB to 32 KB. can we have 64kb and 128kb? > > I used Ardis, Our software, UNH (disk), UNH (file), and UNH > (file-sync). > > UNH (file) uses a file stored on the ext2 file system. > > UNH (file-sync) opens a file with the O_SYNC flag. This guarantees > that the target has written data to disk when the initiator gets the > response of a WRITE command. Note that all target software except UNH > (file) guarantee this semantics. > > I set the number of worker threads 16 with Our software for the better > performance. > > Note that the performance of UNH (file) is best for I/O sizes smaller > than 8KB because the target writes no data to disk during the > benchmark (the ext2 file system delays them and writes them after the > benchmark completes). Over 16KB, some of data are written during the > benchmark. > > Regards, -- -------------------------------------------------- | Ming Zhang, PhD. Student | Dept. of Electrical & Computer Engineering | College of Engineering | University of Rhode Island | Kingston RI. 02881 | e-mail: mingz at ele.uri.edu | Tel. (401) 874-2293 | Fax. (401) 782-6422 | http://www.ele.uri.edu/~mingz/ -------------------------------------------------- |
From: FUJITA T. <to...@ac...> - 2004-06-15 01:42:30
|
Hello, I've attached the results of sequential write tests. o Target CPU : Xeon 2.8GHz Mem : 2GB Disk : Maxtor Atlas 10K SCSI (10000 RPM) / LSI Logic 53C103 NIC : Intel Pro/1000 MT Kernel : 2.4.25 o Initiator CPU : Xeon 2.0GHz Mem : 1GB NIC : Intel Pro/1000 MT Kernel : 2.6.4 The initiator box runs the Cisco iSCSI driver v4.0.1.1 This benchmark sequentially writes data 50,000 times with the I/O sizes ranging from 2KB to 32 KB. I used Ardis, Our software, UNH (disk), UNH (file), and UNH (file-sync). UNH (file) uses a file stored on the ext2 file system. UNH (file-sync) opens a file with the O_SYNC flag. This guarantees that the target has written data to disk when the initiator gets the response of a WRITE command. Note that all target software except UNH (file) guarantee this semantics. I set the number of worker threads 16 with Our software for the better performance. Note that the performance of UNH (file) is best for I/O sizes smaller than 8KB because the target writes no data to disk during the benchmark (the ext2 file system delays them and writes them after the benchmark completes). Over 16KB, some of data are written during the benchmark. Regards, |
From: FUJITA T. <to...@ac...> - 2004-06-14 18:02:08
|
Hi, iSCSI Enterprise Target v0.2.2 has been released. This includes several minor fixes. In addition, the write performance has been improved greatly. I'll post some performance results later. Summary of changes from v0.2.1 to v0.2.2 ================================= FUJITA Tomonori o Improve the write performance of the file IO mode Ming Zhang o Fix unupdated pg_cnt when allocating a new tcmnd o Several cleanups |
From: Ming Z. <mi...@el...> - 2004-06-10 13:24:28
|
I can compile it on 2.4.23 and 26. and this list_for_each_entry_safe shows up since 2.4.23 ming On Thu, 2004-06-10 at 06:58, franklin w wrote: > Thanks for your help, Tomo. > My kernel is purely 2.4.20, with your patch , i compiled successfully. >=20 > BTW. which version of the kernel does you work on ? >=20 >=20 > >From: FUJITA Tomonori <to...@ac...> > >To: isc...@li... > >CC: yf...@ho... > >Subject: Re: [Iscsitarget-devel] HELP: comile error > >Date: Thu, 10 Jun 2004 14:57:20 +0900 > > > >Hi, > > > >Thanks for trying the new versions. > > > >From: "franklin w" <yf...@ho...> > >Subject: [Iscsitarget-devel] HELP: comile error > >Date: Thu, 10 Jun 2004 13:30:44 +0800 > > > >It seems that old kernels don't have the list_for_each_entry_safe > >func. I've attached a patch. Please try it. > > > >I'm not sure that this patch can work with a Redhat 8.0 (I don't use > >any Redhat's version). But it works with the stock 2.4.20 kernel. > > > >Regards, > >-- > >tomo > ><< oldkernel.diff >> >=20 > _________________________________________________________________ > =E4=B8=8E=E8=81=94=E6=9C=BA=E7=9A=84=E6=9C=8B=E5=8F=8B=E8=BF=9B=E8=A1=8C= =E4=BA=A4=E6=B5=81=EF=BC=8C=E8=AF=B7=E4=BD=BF=E7=94=A8 MSN Messenger: ht= tp://messenger.msn.com/cn =20 >=20 >=20 >=20 > ------------------------------------------------------- > This SF.Net email is sponsored by: GNOME Foundation > Hackers Unite! GUADEC: The world's #1 Open Source Desktop Event. > GNOME Users and Developers European Conference, 28-30th June in Norway > http://2004/guadec.org > _______________________________________________ > Iscsitarget-devel mailing list > Isc...@li... > https://lists.sourceforge.net/lists/listinfo/iscsitarget-devel --=20 -------------------------------------------------- | Ming Zhang, PhD. Student | Dept. of Electrical & Computer Engineering | College of Engineering | University of Rhode Island | Kingston RI. 02881 | e-mail: mingz at ele.uri.edu | Tel. (401) 874-2293=20 | Fax. (401) 782-6422 | http://www.ele.uri.edu/~mingz/ -------------------------------------------------- |
From: franklin w <yf...@ho...> - 2004-06-10 10:59:49
|
Thanks for your help, Tomo. My kernel is purely 2.4.20, with your patch , i compiled successfully. BTW. which version of the kernel does you work on ? >From: FUJITA Tomonori <to...@ac...> >To: isc...@li... >CC: yf...@ho... >Subject: Re: [Iscsitarget-devel] HELP: comile error >Date: Thu, 10 Jun 2004 14:57:20 +0900 > >Hi, > >Thanks for trying the new versions. > >From: "franklin w" <yf...@ho...> >Subject: [Iscsitarget-devel] HELP: comile error >Date: Thu, 10 Jun 2004 13:30:44 +0800 > >It seems that old kernels don't have the list_for_each_entry_safe >func. I've attached a patch. Please try it. > >I'm not sure that this patch can work with a Redhat 8.0 (I don't use >any Redhat's version). But it works with the stock 2.4.20 kernel. > >Regards, >-- >tomo ><< oldkernel.diff >> _________________________________________________________________ 与联机的朋友进行交流,请使用 MSN Messenger: http://messenger.msn.com/cn |
From: FUJITA T. <to...@ac...> - 2004-06-10 05:57:23
|
Hi, Thanks for trying the new versions. From: "franklin w" <yf...@ho...> Subject: [Iscsitarget-devel] HELP: comile error Date: Thu, 10 Jun 2004 13:30:44 +0800 > when i compile v2.0 and v2.1, the following error happedn at both > situations. > (my machine : redhat8.0 + kernel 2.4.20) > __________________ > > .......... > gcc -D__KERNEL__ -I/usr/src/linux-2.4.20/include -Wall -Wstrict-prototypes > -Wno- > trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe > -mpref > erred-stack-boundary=2 -march=i686 -DMODULE -DMODVERSIONS -include > /usr/src/linu > x-2.4.20/include/linux/modversions.h -nostdinc -iwithprefix include > -DKBUILD_BA > SENAME=conn -c -o conn.o conn.c > conn.c: In function `cleanup_write_list': > conn.c:87: warning: implicit declaration of function > `list_for_each_entry_safe' It seems that old kernels don't have the list_for_each_entry_safe func. I've attached a patch. Please try it. I'm not sure that this patch can work with a Redhat 8.0 (I don't use any Redhat's version). But it works with the stock 2.4.20 kernel. Regards, -- tomo |
From: franklin w <yf...@ho...> - 2004-06-10 05:31:35
|
when i compile v2.0 and v2.1, the following error happedn at both situations. (my machine : redhat8.0 + kernel 2.4.20) __________________ .......... gcc -D__KERNEL__ -I/usr/src/linux-2.4.20/include -Wall -Wstrict-prototypes -Wno- trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpref erred-stack-boundary=2 -march=i686 -DMODULE -DMODVERSIONS -include /usr/src/linu x-2.4.20/include/linux/modversions.h -nostdinc -iwithprefix include -DKBUILD_BA SENAME=conn -c -o conn.o conn.c conn.c: In function `cleanup_write_list': conn.c:87: warning: implicit declaration of function `list_for_each_entry_safe' conn.c:87: `list' undeclared (first use in this function) conn.c:87: (Each undeclared identifier is reported only once conn.c:87: for each function it appears in.) conn.c:87: parse error before '{' token conn.c: At top level: conn.c:92: parse error before "do" conn.c: In function `cleaup_ready_lists': conn.c:107: `list' undeclared (first use in this function) conn.c:107: parse error before '{' token conn.c:100: warning: unused variable `func' conn.c:101: warning: unused variable `count' conn.c: At top level: conn.c:112: parse error before "else" conn.c:116: parse error before '&' token conn.c:116: warning: type defaults to `int' in declaration of `spin_unlock' conn.c:116: warning: function declaration isn't a prototype conn.c:116: conflicting types for `spin_unlock' /usr/src/linux-2.4.20/include/asm/spinlock.h:81: previous declaration of `spin_u nlock' conn.c:116: warning: data definition has no type or storage class conn.c:118: parse error before '&' token conn.c:118: warning: return type defaults to `int' conn.c:118: warning: function declaration isn't a prototype conn.c: In function `list_for_each_entry_safe': conn.c:119: `cmnd' undeclared (first use in this function) conn.c:124: `func' undeclared (first use in this function) conn.c:125: `func' used prior to declaration conn.c:125: warning: implicit declaration of function `func' conn.c:126: `count' undeclared (first use in this function) conn.c: At top level: conn.c:129: parse error before "do" conn.c: In function `cleanup_r2t_cmnds': conn.c:139: `conn_list' undeclared (first use in this function) conn.c:139: parse error before '{' token conn.c: At top level: conn.c:149: parse error before "do" conn.c: In function `cleanup_r2t_req_cmnds': conn.c:158: `conn_list' undeclared (first use in this function) conn.c:158: parse error before '{' token conn.c: At top level: conn.c:170: parse error before "do" conn.c: In function `dump_cmnds': conn.c:178: `conn_list' undeclared (first use in this function) conn.c:178: parse error before '{' token conn.c:176: warning: unused variable `count' make[2]: *** [conn.o] Error 1 make[2]: Leaving directory `/root/iscsi/iscsitarget-0.2.0/kernel' make[1]: *** [_mod_/root/iscsi/iscsitarget-0.2.0/kernel] Error 2 make[1]: Leaving directory `/usr/src/linux-2.4.20' make: *** [mods] Error 2 Thanks. _________________________________________________________________ 与联机的朋友进行交流,请使用 MSN Messenger: http://messenger.msn.com/cn |
From: FUJITA T. <to...@ac...> - 2004-06-08 13:56:32
|
Hi, iSCSI Enterprise Target v0.2.1 has been released because v0.2.0 has a bug that hogs CPU unnecessarily. This version includes a simple feature that enables you to pass parameters to an IO mode. For example, if the iscsid.config file includes the following line, Lun 0 /dev/hdc fileio abc def the fileio module gets "abc def" at startup. If you want your own IO mode, this can be useful. Summary of changes from v0.2.0 to v0.2.1 ================================= FUJITA Tomonori o Fix a bug that makes the target use CPU unnecessarily o Add a feature that enable you to pass options to an IO mode |
From: FUJITA T. <to...@ac...> - 2004-06-07 14:21:44
|
Hi, iSCSI Enterprise Target v0.2.0 has been released. Please download and try it. Now you can repeat the login and logout processes over and over, and shutdown the target cleanly After you make sure that all initiators disconnect from the target, execute: ./iscsitarget-0.2.0/initd stop This shutdowns the target and removes the modules (if you use fileio). Note that the shutdown code is not finished. If you shutdown the target having an established connection with an initiator, you may have a problem. We'll fix it, so please be patient. Summary of changes from v0.1.0 to v0.2.0 ================================= FUJITA Tomonori o Rewrite read and write kernel threads which perform network IO o Fix race issues in the proc interface o Fix shutdown code Ming Zhang o Fix memory leaks in file and block IO modes |
From: Ming Z. <mi...@el...> - 2004-06-01 23:47:15
|
Hi, current makefile can only be used under 2.4.x. the makefile is quite different under 2.4 and 2.6 so a 2.4 makefile will 100% fail under 2.6. we are working toward a 2.6 release but currently please stick to 2.4.x. because of some issues, we can not move to 2.6 before we solve them. thanks for your patience. ming On Tue, 2004-06-01 at 18:10, Bill Love wrote: > Hi- > It has been suggested that this topic be moved to the mailing lists > from the forum so here I am :) I am looking for support for FC2 and the > 2.6.5-1... kernel supplied within. I get the same errors that Hugo Samayoa > gets plus a few more that appear to be a problem with the Makefile not > including the correct directories from the <kernel-src> tree for things like > linux/include and linux/asm. > > There is a rumor that a patch exists for 2.6 that might help eliminate some > of > these issues. I'd love to give it a try even if it is pre-alpha as well. > > Thx. > > Bill Love > lo...@sh... > 508-380-8877 > > > > ------------------------------------------------------- > This SF.Net email is sponsored by the new InstallShield X. > >From Windows to Linux, servers to mobile, InstallShield X is the one > installation-authoring solution that does it all. Learn more and > evaluate today! http://www.installshield.com/Dev2Dev/0504 > _______________________________________________ > Iscsitarget-devel mailing list > Isc...@li... > https://lists.sourceforge.net/lists/listinfo/iscsitarget-devel -- -------------------------------------------------- | Ming Zhang, PhD. Student | Dept. of Electrical & Computer Engineering | College of Engineering | University of Rhode Island | Kingston RI. 02881 | e-mail: mingz at ele.uri.edu | Tel. (401) 874-2293 | Fax. (401) 782-6422 | http://www.ele.uri.edu/~mingz/ -------------------------------------------------- |
From: Bill L. <lo...@sh...> - 2004-06-01 22:10:49
|
Hi- It has been suggested that this topic be moved to the mailing lists from the forum so here I am :) I am looking for support for FC2 and the 2.6.5-1... kernel supplied within. I get the same errors that Hugo Samayoa gets plus a few more that appear to be a problem with the Makefile not including the correct directories from the <kernel-src> tree for things like linux/include and linux/asm. There is a rumor that a patch exists for 2.6 that might help eliminate some of these issues. I'd love to give it a try even if it is pre-alpha as well. Thx. Bill Love lo...@sh... 508-380-8877 |
From: Michael L. <mik...@ad...> - 2004-06-01 21:00:06
|
My Bad.... It is at http://iscsitarget.sourceforge.net/faq.html -----Original Message----- From: isc...@li... [mailto:isc...@li...urceforge. net]On Behalf Of Michael Levine Sent: Tuesday, June 01, 2004 4:57 PM To: isc...@li... Subject: RE: [Iscsitarget-devel] Removing the iSCSI module Where is the FAQ? -----Original Message----- From: isc...@li... [mailto:isc...@li...urceforge. net]On Behalf Of Ming Zhang Sent: Tuesday, June 01, 2004 4:39 PM To: mik...@ad... Cc: isc...@li... Subject: Re: [Iscsitarget-devel] Removing the iSCSI module as in the faq, there are still some issues in cleanup code thus u can not remove the target module successfully. we are working on it. sorry for this. :) ming On Tue, 2004-06-01 at 16:34, mik...@ad... wrote: > Sorry if this has been covered before but there are no list archives. > > How can I remove all traces of the iSCSI module from the kernel. > I cannot rmmod the modules and I cannot kill the kernel threads. > I can kill the iscsi_trgtd daemon but that still will not let me remove the modules. > > Thanks > Mike Levine > > > ------------------------------------------------ ------- > This SF.Net email is sponsored by the new InstallShield X. > >From Windows to Linux, servers to mobile, InstallShield X is the one > installation-authoring solution that does it all. Learn more and > evaluate today! http://www.installshield.com/Dev2Dev/0504 > _______________________________________________ > Iscsitarget-devel mailing list > Isc...@li... > https://lists.sourceforge.net/lists/listinfo/iscsi target-devel -- ------------------------------------------------- - | Ming Zhang, PhD. Student | Dept. of Electrical & Computer Engineering | College of Engineering | University of Rhode Island | Kingston RI. 02881 | e-mail: mingz at ele.uri.edu | Tel. (401) 874-2293 | Fax. (401) 782-6422 | http://www.ele.uri.edu/~mingz/ ------------------------------------------------- - -------------------------------------------------- ----- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 _______________________________________________ Iscsitarget-devel mailing list Isc...@li... https://lists.sourceforge.net/lists/listinfo/iscsi target-devel -------------------------------------------------- ----- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 _______________________________________________ Iscsitarget-devel mailing list Isc...@li... https://lists.sourceforge.net/lists/listinfo/iscsi target-devel |
From: Michael L. <mik...@ad...> - 2004-06-01 20:55:44
|
Where is the FAQ? -----Original Message----- From: isc...@li... [mailto:isc...@li...urceforge. net]On Behalf Of Ming Zhang Sent: Tuesday, June 01, 2004 4:39 PM To: mik...@ad... Cc: isc...@li... Subject: Re: [Iscsitarget-devel] Removing the iSCSI module as in the faq, there are still some issues in cleanup code thus u can not remove the target module successfully. we are working on it. sorry for this. :) ming On Tue, 2004-06-01 at 16:34, mik...@ad... wrote: > Sorry if this has been covered before but there are no list archives. > > How can I remove all traces of the iSCSI module from the kernel. > I cannot rmmod the modules and I cannot kill the kernel threads. > I can kill the iscsi_trgtd daemon but that still will not let me remove the modules. > > Thanks > Mike Levine > > > ------------------------------------------------ ------- > This SF.Net email is sponsored by the new InstallShield X. > >From Windows to Linux, servers to mobile, InstallShield X is the one > installation-authoring solution that does it all. Learn more and > evaluate today! http://www.installshield.com/Dev2Dev/0504 > _______________________________________________ > Iscsitarget-devel mailing list > Isc...@li... > https://lists.sourceforge.net/lists/listinfo/iscsi target-devel -- ------------------------------------------------- - | Ming Zhang, PhD. Student | Dept. of Electrical & Computer Engineering | College of Engineering | University of Rhode Island | Kingston RI. 02881 | e-mail: mingz at ele.uri.edu | Tel. (401) 874-2293 | Fax. (401) 782-6422 | http://www.ele.uri.edu/~mingz/ ------------------------------------------------- - -------------------------------------------------- ----- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 _______________________________________________ Iscsitarget-devel mailing list Isc...@li... https://lists.sourceforge.net/lists/listinfo/iscsi target-devel |
From: Ming Z. <mi...@el...> - 2004-06-01 20:39:29
|
as in the faq, there are still some issues in cleanup code thus u can not remove the target module successfully. we are working on it. sorry for this. :) ming On Tue, 2004-06-01 at 16:34, mik...@ad... wrote: > Sorry if this has been covered before but there are no list archives. > > How can I remove all traces of the iSCSI module from the kernel. > I cannot rmmod the modules and I cannot kill the kernel threads. > I can kill the iscsi_trgtd daemon but that still will not let me remove the modules. > > Thanks > Mike Levine > > > ------------------------------------------------------- > This SF.Net email is sponsored by the new InstallShield X. > >From Windows to Linux, servers to mobile, InstallShield X is the one > installation-authoring solution that does it all. Learn more and > evaluate today! http://www.installshield.com/Dev2Dev/0504 > _______________________________________________ > Iscsitarget-devel mailing list > Isc...@li... > https://lists.sourceforge.net/lists/listinfo/iscsitarget-devel -- -------------------------------------------------- | Ming Zhang, PhD. Student | Dept. of Electrical & Computer Engineering | College of Engineering | University of Rhode Island | Kingston RI. 02881 | e-mail: mingz at ele.uri.edu | Tel. (401) 874-2293 | Fax. (401) 782-6422 | http://www.ele.uri.edu/~mingz/ -------------------------------------------------- |
From: <mik...@ad...> - 2004-06-01 20:33:32
|
Sorry if this has been covered before but there are no list archives. How can I remove all traces of the iSCSI module from the kernel. I cannot rmmod the modules and I cannot kill the kernel threads. I can kill the iscsi_trgtd daemon but that still will not let me remove the modules. Thanks Mike Levine |
From: <to...@ac...> - 2004-05-31 15:42:44
|
From: Maffione Eugenio <Eugenio.Maffione@TILAB.COM> Subject: [Iscsitarget-devel] RE: Ang: Fw: Re: New iSCSI target project Date: Mon, 31 May 2004 10:15:37 +0200 > I've prepared some exciting ppt (sorry, my company use win2k as office > platform) about the "flexible storage gateway concept" that I'd like to > share & discuss with you. They could be the base of our doc. Let me know > if you are interested. Please attach the ppt. Let's discuss it. |
From: Ming Z. <mi...@el...> - 2004-05-31 13:32:58
|
Hi, I think this is a problem coming from rh9.0. what kernel version coming with redhat 9 now? ming On Sun, 2004-05-30 at 14:55, G=C3=B6ransson Magnus wrote: > Hello all of you! >=20 > =20 >=20 > This seems to be the software i really need! >=20 > =20 >=20 > I=E2=80=99m planning a setup of a Microsoft Cluster here at home and th= e > problem with a MS Cluster is the requirement of having shared disks. > To use shared disks you=E2=80=99ll have to have SCSI-Disks or a SAN. iS= CSI > seems to be the soloution for me, at least for testing purposes. >=20 > =20 >=20 > However, when I try to install the software I get some error messages: >=20 > =20 >=20 > [root@san01 iscsitarget-0.1.0]# make KERNELSRC=3D/usr/src/linux-2.4 >=20 > <a lot of text> >=20 > /usr/src/linux-2.4.20-8/include/asm/uaccess.h:603: > `clear_user_R_ver_str' declared as function returning a function >=20 > /usr/src/linux-2.4.20-8/include/asm/uaccess.h:603: warning: function > declaration isn't a prototype >=20 > /usr/src/linux-2.4.20-8/include/asm/uaccess.h:604: > `__clear_user_R_ver_str' declared as function returning a function >=20 > /usr/src/linux-2.4.20-8/include/asm/uaccess.h:604: warning: parameter > names (without types) in function declaration >=20 > target.c: In function `target_cmnd_alloc': >=20 > target.c:28: warning: implicit declaration of function > `printk_R1b7d4074' >=20 > make[2]: *** [target.o] Error 1 >=20 > make[2]: Leaving directory > `/usr/src/iscsi-target/iscsitarget-0.1.0/kernel' >=20 > make[1]: *** [_mod_/usr/src/iscsi-target/iscsitarget-0.1.0/kernel] > Error 2 >=20 > make[1]: Leaving directory `/usr/src/linux-2.4.20-8' >=20 > make: *** [mods] Error 2 >=20 > [root@san01 iscsitarget-0.1.0]# >=20 > [root@san01 iscsitarget-0.1.0]# >=20 > =20 >=20 > Is there a way to get around this problem? I=E2=80=99m not very experie= nced > with linux=E2=80=A6 However it=E2=80=99s RedHat 9.0. >=20 > =20 >=20 > /Magnus --=20 -------------------------------------------------- | Ming Zhang, PhD. Student | Dept. of Electrical & Computer Engineering | College of Engineering | University of Rhode Island | Kingston RI. 02881 | e-mail: mingz at ele.uri.edu | Tel. (401) 874-2293=20 | Fax. (401) 782-6422 | http://www.ele.uri.edu/~mingz/ -------------------------------------------------- |
From: Ming Z. <mi...@el...> - 2004-05-31 13:31:36
|
:P i think i can understand what u mean and i agree with all your comments. i think i am a little eager. :) once we fix the must fix thing in 2.4, as u said, we should forget the 2.4 and turn to 2.6 since that is the trend. let's work hard to see earlier it comes. :P i would like the ppt. i have openoffice to open it even i have no windows platform now. :P ming On Mon, 2004-05-31 at 04:15, Maffione Eugenio wrote: > I agree with you. Also in my opinion, at the moment, with the actual > resources, it is better to fix the "must-fix" things with 2.4. > Everybody agrees that 2.6 is the future and we should clearly declare it > in our roadmap, explaining our position: fix the must-fix and then pass > toward 2.6. > I think that starting *now* a 2.6 branch could waste the focus on the > project ... > Anyway, we could invite some developers to *thing about* the porting, > without official releases, in the mean time, so, as soon as we have the > fixes, we could release a 2.6 porting because of this advance. > > It seems that the project is collecting every day more interest. Could > we put on the site some documentation explaining our ideas? > > I've prepared some exciting ppt (sorry, my company use win2k as office > platform) about the "flexible storage gateway concept" that I'd like to > share & discuss with you. They could be the base of our doc. Let me know > if you are interested. > > Eugenio > > > > > > -----Original Message----- > From: to...@ac... [mailto:to...@ac...] > Sent: Sunday, May 30, 2004 5:57 PM > To: isc...@li... > Cc: mi...@el...; Eugenio.Maffione@TILAB.COM; > joh...@ca... > Subject: RE: Ang: Fw: Re: New iSCSI target project > > > Hello, > > Let's discuss this at the mailing list. > > From: Ming Zhang <mi...@el...> > Subject: RE: Ang: Fw: Re: New iSCSI target project > Date: Sat, 29 May 2004 16:00:43 -0400 > > > Hi, I am wondering if we can have a code tree that has 2.4 and 2.6 > > coexist like what I did in UNH code. Providing Makefile-2.4 and > > Makefile-2.6 and use defines to process 2.4 and 2.6 different when > > need. If that 2.6 code is workable, then we should shift our attention > > > to 2.6 since that is the trend. While we still keep 2.4 code in it > > because that is more mature. > > Don't Put "ifdef" directly in the C source like done in UNH code (see > http://www.linuxjournal.com/article.php?sid=5780). > > Just coexisting is easy. But I want to reimplement several functions > with the 2.6 kernel for performance. So the difference would be bigger. > > I don't think that there are enough resources for maintaining two > versions. So we have to give up the version for the 2.4 at some future > time. > > I want to go with the 2.6 kernel. But I want to fix some of must-fix > things in the todo list before that. > > > Regards, > -- > tomo > > > Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia S.p.A. > > ==================================================================== > CONFIDENTIALITY NOTICE > This message and its attachments are addressed solely to the persons > above and may contain confidential information. If you have received > the message in error, be informed that any use of the content hereof > is prohibited. Please return it immediately to the sender and delete > the message. Should you have any questions, please send an e_mail to > Mai...@ti.... Thank you > ==================================================================== -- -------------------------------------------------- | Ming Zhang, PhD. Student | Dept. of Electrical & Computer Engineering | College of Engineering | University of Rhode Island | Kingston RI. 02881 | e-mail: mingz at ele.uri.edu | Tel. (401) 874-2293 | Fax. (401) 782-6422 | http://www.ele.uri.edu/~mingz/ -------------------------------------------------- |
From: Maffione E. <Eugenio.Maffione@TILAB.COM> - 2004-05-31 08:15:47
|
I agree with you. Also in my opinion, at the moment, with the actual resources, it is better to fix the "must-fix" things with 2.4. Everybody agrees that 2.6 is the future and we should clearly declare it in our roadmap, explaining our position: fix the must-fix and then pass toward 2.6. I think that starting *now* a 2.6 branch could waste the focus on the project ... Anyway, we could invite some developers to *thing about* the porting, without official releases, in the mean time, so, as soon as we have the fixes, we could release a 2.6 porting because of this advance. It seems that the project is collecting every day more interest. Could we put on the site some documentation explaining our ideas? I've prepared some exciting ppt (sorry, my company use win2k as office platform) about the "flexible storage gateway concept" that I'd like to share & discuss with you. They could be the base of our doc. Let me know if you are interested. Eugenio -----Original Message----- From: to...@ac... [mailto:to...@ac...]=20 Sent: Sunday, May 30, 2004 5:57 PM To: isc...@li... Cc: mi...@el...; Eugenio.Maffione@TILAB.COM; joh...@ca... Subject: RE: Ang: Fw: Re: New iSCSI target project Hello, Let's discuss this at the mailing list. From: Ming Zhang <mi...@el...> Subject: RE: Ang: Fw: Re: New iSCSI target project Date: Sat, 29 May 2004 16:00:43 -0400 > Hi, I am wondering if we can have a code tree that has 2.4 and 2.6=20 > coexist like what I did in UNH code. Providing Makefile-2.4 and=20 > Makefile-2.6 and use defines to process 2.4 and 2.6 different when=20 > need. If that 2.6 code is workable, then we should shift our attention > to 2.6 since that is the trend. While we still keep 2.4 code in it=20 > because that is more mature. Don't Put "ifdef" directly in the C source like done in UNH code (see http://www.linuxjournal.com/article.php?sid=3D5780). Just coexisting is easy. But I want to reimplement several functions with the 2.6 kernel for performance. So the difference would be bigger. I don't think that there are enough resources for maintaining two versions. So we have to give up the version for the 2.4 at some future time. I want to go with the 2.6 kernel. But I want to fix some of must-fix things in the todo list before that. Regards, -- tomo Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia = S.p.A. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please send an e_mail to=20 Mai...@ti.... Thank you =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D |
From: <fuj...@la...> - 2004-05-31 04:44:42
|
Hi, Thanks for the comments. From: "franklin w" <yf...@ho...> Subject: [Iscsitarget-devel] questions and comments Date: Mon, 31 May 2004 11:04:49 +0800 > 1. in faq, > "Can I configure security policy per a LUN? Yes. " > Is security policy is configured per a Lu? It is per > Target according to iSCSI spec. If you support only one Lu in > a target, you may say that. is it that so? Sorry, my choice of words seems to lead to confusion. I'll try to follow the iSCSI spec rule strictly. Our software supports multiple targets. A single target handle multiple LUNs. And you can configure security policy per a target. I'll correct the clause later. > 2.about flexible IO architecture > I think this is a good idea and I have imagined it for a long time. > I have not dive into your code and don't know weather i could add another > io mode easily(fg. a io mode like diskio in UNH). It's really easy, I think. FYI, Ming has a plan to implement an IO mode like diskio in UNH. So if you do, please discuss it with him. > Additionaly, i have a question on choice of I/O interface. For performnace > considerations,there are two relevant factors: system cache, length of I/O I did some performance tests on Ardis and UNH diskio and fileio. With sequential-write tests, I saw the small effects due to the length of I/O path. However, with a postmark benchmark, there is no affect due to it. On the other hand, with read-intensive workloads, page cache affects the performance greatly. I think that in most cases, a fileio mode works fine for you. > 3. I think there is puzzle on the use of target. > "I succeed to make two UNH initiators connect with a single target just > now. The target exports two target names. Both initiators connect with one > target name." > > I think the folloing expressing should be more clear: > A iSCSI (target) server ,which runs on a network entity, can be configured > to exporting multi target. Agreed. Bye, -- tomo |