Date: Tue, 22 Nov 2005 17:22:00 +0100 (CET) From: Wojciech Puchar <wojtek@tensor.3miasto.net> To: Dan Nelson <dnelson@allantgroup.com> Cc: freebsd-questions@freebsd.org, John Oxley <john@yoafrica.com> Subject: Re: iSCSI support Message-ID: <20051122171702.H9431@chylonia.3miasto.net> In-Reply-To: <20051122160343.GB6893@dan.emsphone.com> References: <43824EF0.8090807@endries.org> <20051122002352.G75644@chylonia.3miasto.net> <20051122062506.GD13838@yoafrica.com> <20051122121855.J89225@chylonia.3miasto.net> <20051122160343.GB6893@dan.emsphone.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>> just a cheap PC with cheap IDE drives.. > > Whole devices accessed directly can be a lot faster than NFS, since the > client doesn't have to constantly ask the NFS server whether the file > it's currently accessing has changed. any problem to add such option to NFS?? with iSCSI you just CAN't do it. anyway this asking isn't bandwidth intensive, while adds delays. and it may affect of transfer speed for ONE process reading one file, but not multiuser system. > > And when a cheap IDE in one of the 100 servers in your server room goes > out, you have to find the server, figure out which drives it has in it > and which RAID controller it has, go to your spares cabinet and get the if company having this 100 servers (must be really huge company or really bad software using to need 100 servers) and their IT managers don't know what it where and don't know few basic unix command to localize the problem source - then here is a problem, and any kind of SAN won't fix it. the real fix is to employ someone more competent.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051122171702.H9431>