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 1NrZhn-00040r-QL for garchives@archives.gentoo.org; Tue, 16 Mar 2010 16:33:20 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 49D52E0ADB; Tue, 16 Mar 2010 16:32:31 +0000 (UTC) Received: from smtp.hotchilli.net (mta3.th.hotchilli.net [62.89.140.53]) by pigeon.gentoo.org (Postfix) with ESMTP id 0B4ECE0ADB for ; Tue, 16 Mar 2010 16:32:30 +0000 (UTC) Received: from static-87-243-200-80.adsl.hotchilli.net ([87.243.200.80] helo=[10.0.1.253]) by smtp.hotchilli.net with esmtp (Exim 4.63) (envelope-from ) id 1NrZgz-0004EO-Ro for gentoo-user@lists.gentoo.org; Tue, 16 Mar 2010 16:32:29 +0000 Message-ID: <4B9FB29D.7010902@shic.co.uk> Date: Tue, 16 Mar 2010 16:32:29 +0000 From: Steve User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.8) Gecko/20100227 Lightning/1.0b1 Thunderbird/3.0.3 ThunderBrowse/3.2.8.1 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] Re: 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> In-Reply-To: <4B9EB4B6.9040106@alyf.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Archives-Salt: 38cb0701-89fb-415e-8bf3-88f9a3cf7e3d X-Archives-Hash: 32e357a3084135bc098b5bb7ad39f7df On 15/03/2010 22:29, Andrea Conti wrote: > This IMHO pretty much rules out any kind of server-class hardware, which > tends to be both costly and power-hungry. If you're thinking about > buying used stuff, be sure to factor in the cost and difficulty of > finding spares in some years' time. > I'm considering neither used equipment nor 'server-class' - the workload simply doesn't demand it. > Given the point above I would also stick with software RAID. ... > If reliability is your primary concern, I would go for a simple RAID1 > setup; Absolutely. Software raid is cheaper and implies less hardware to fail. Similarly, RAID1 minimises the total number of disks required to survive a failure. It's the only way for me to go. > If you do not need data sharing (i.e. if your volumes are only mounted > by one client at a time), the simplest solution is to completely avoid > having a FS on the storage server side -- just export the raw block > device via iSCSI, and do everything on the client. This idea is on my wavelength. Has anyone on this tried this? My concerns are: 1. Are there reliability issues surrounding this technology in Gentoo? 2. Are there any howtos about putting as much of the file-system as possible onto an iSCSI device. 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. Can (cheap) NAS devices be used to export iSCSI to Gentoo? 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. > In my experience this also works very well with Windows clients using the free MS iSCSI initiator. > That's fantastic - I had no idea that such software existed. Now, I wonder, what's the most lightweight solution to get a couple of iSCSI devices? Does it help that MS supports attaching devices this way? > File systems: avoid complexity. As technically superior as it might be, > in this kind of setup ZFS is only going to be resource hog and a > maintenance headache; your priority should be having a rock-solid > implementation and a reliable set of diagnostic/repair tools in case > disaster strikes. Yes. Separate arguments for snapshot support are compelling... but there are alternatives without tackling the additional complexity. That said, the iSCSI approach would work as well with ZFS as something mundane. 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.