From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1NrgmB-0002zY-0z for garchives@archives.gentoo.org; Wed, 17 Mar 2010 00:06:22 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 4BC89E0D05; Wed, 17 Mar 2010 00:06:03 +0000 (UTC) Received: from smtp-out30.alice.it (smtp-out30.alice.it [85.33.2.30]) by pigeon.gentoo.org (Postfix) with ESMTP id 04987E0D22 for ; Wed, 17 Mar 2010 00:06:02 +0000 (UTC) Received: from FBCMMO04.fbc.local ([192.168.184.135]) by smtp-out30.alice.it with Microsoft SMTPSVC(6.0.3790.3959); Wed, 17 Mar 2010 01:06:02 +0100 Received: from FBCMCL01B08.fbc.local ([192.168.171.46]) by FBCMMO04.fbc.local with Microsoft SMTPSVC(6.0.3790.3959); Wed, 17 Mar 2010 01:05:11 +0100 Received: from infra.agr.fm ([79.40.116.89]) by FBCMCL01B08.fbc.local with Microsoft SMTPSVC(6.0.3790.3959); Wed, 17 Mar 2010 01:05:09 +0100 Received: from [192.168.64.9] (silver.agr.fm [192.168.64.9]) by infra.agr.fm (Postfix) with ESMTP id EA6D45DD16A for ; Wed, 17 Mar 2010 01:05:18 +0100 (CET) Message-ID: <4BA01CB5.5030300@alyf.net> Date: Wed, 17 Mar 2010 01:05:09 +0100 From: Andrea Conti User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Strategy for using SAN/NAS for storage with Gentoo... References: <4B9E343A.4040908@shic.co.uk> <87d3z53b2u.fsf@newsguy.com> <854dca5c1003150849l16b375ddl89ad2e20a8f6a135@mail.gmail.com> <4B9E5FA4.1040501@shic.co.uk> <7D7A990E-4680-472D-8408-FFABFE82EDBA@stellar.eclipse.co.uk> <4B9E87FA.3090600@shic.co.uk> <4B9EB4B6.9040106@alyf.net> <4B9FB29D.7010902@shic.co.uk> In-Reply-To: <4B9FB29D.7010902@shic.co.uk> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Mar 2010 00:05:09.0968 (UTC) FILETIME=[822A9D00:01CAC565] X-Archives-Salt: f626cb14-8c6e-4e3e-b10f-2926ed7718ed X-Archives-Hash: 38a09ffe5429ceed2e205e34c0c88bee > 1. Are there reliability issues surrounding this technology in Gentoo? My only experience is with a Gentoo-based iSCSI target (ie. "server"); my clients are windows-based. The system is a low-end Core 2 duo running the latest stable kernel and Iscsi Enterprise Target; I have been running this setup non-stop for a couple of years and it has proven quite stable. iSCSI is designed with a dedicated, reliable network in mind, and in my experience it is quite sensitive to network connectivity issues. It is best used over gigabit ethernet; fast ethernet is ok, too, if you don't care about performace. Avoid WiFi if you value your data (and your mental health) > 2. Are there any howtos about putting as much of the file-system as > possible onto an iSCSI device. Google "root over iscsi". For example: http://wpkg.org/Diskless_/_remote_boot_with_Open-iSCSI I have _not_ tried it. It is an interesting concept, but I think that the OS is better left on a local disk -- the performance penalty is way too great, especially with the king of budget-oriented storage backend you are considering. > 3. What's the best (most lightweight) way to expose the disk as a > block device. I don't want to manage three fully-fledged Linux boxes. The only software you need is an iSCSI initiator: a minimal Gentoo install running sys-block/iscsitarget is enough. IET allows you to export any kind of raw block device (a disk, a partition, a RAID volume,...) or even a file on a local filesystem. Or perhaps you can look into FreeNAS (http://freenas.org), which is less flexible than a full-fledged OS install but might be enough in your case. > Can (cheap) NAS devices be used to export iSCSI to Gentoo? If the NAS device can "speak" iSCSI, well, yes. > 4. What would be the strategy to 'secure' this iSCSI device... it would > be a disaster if my WiFi were cracked and my data corrupted from a > non-authorised host. iSCSI connections are authenticated with a challenge-response mechanism; in IET you can also restrict access to specific hosts on a per-volume basis. That should be enough if you are not transferring the data itself over WiFi, which is a Bad Thing and should not be done. > Snap-shots, of course, are only really valuable for non-archive data... > so, in future, I could add a ZFS volume using the same iSCSI strategy. ZFS allows you to take FS-level snapshots -- with iSCSI that would be on the client, onto a network-connected volume, and I don't know what kind of performance implications that has. If you want to take snapshots on the server, my first thought would be to do so at the block level using LVM. No idea if it plays well with IET, though. andrea