From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id C881313838B for ; Wed, 17 Sep 2014 07:45:08 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id C802BE08C7; Wed, 17 Sep 2014 07:45:03 +0000 (UTC) Received: from smtpq5.tb.mail.iss.as9143.net (smtpq5.tb.mail.iss.as9143.net [212.54.42.168]) by pigeon.gentoo.org (Postfix) with ESMTP id AFBDAE08B0 for ; Wed, 17 Sep 2014 07:45:02 +0000 (UTC) Received: from [212.54.42.137] (helo=smtp6.tb.mail.iss.as9143.net) by smtpq5.tb.mail.iss.as9143.net with esmtp (Exim 4.76) (envelope-from ) id 1XU9vC-0003LP-0M for gentoo-user@lists.gentoo.org; Wed, 17 Sep 2014 09:45:02 +0200 Received: from 53579160.cm-6-8c.dynamic.ziggo.nl ([83.87.145.96] helo=data.antarean.org) by smtp6.tb.mail.iss.as9143.net with esmtp (Exim 4.76) (envelope-from ) id 1XU9vB-00006P-K7 for gentoo-user@lists.gentoo.org; Wed, 17 Sep 2014 09:45:01 +0200 Received: from andromeda.localnet (unknown [62.41.73.83]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by data.antarean.org (Postfix) with ESMTPSA id B0EF34B for ; Wed, 17 Sep 2014 09:44:38 +0200 (CEST) From: "J. Roeleveld" To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] File system testing Date: Wed, 17 Sep 2014 09:45:14 +0200 Message-ID: <1702192.KJn5UXzBYJ@andromeda> Organization: Antarean User-Agent: KMail/4.12.5 (Linux/3.14.14-gentoo; KDE/4.12.5; x86_64; ; ) In-Reply-To: References: 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 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Ziggo-spambar: ---- X-Ziggo-spamscore: -4.8 X-Ziggo-spamreport: ALL_TRUSTED=-1,BAYES_00=-1.9,PROLO_TRUST_RDNS=-3,RDNS_DYNAMIC=0.982,TW_ZF=0.077 X-Ziggo-Spam-Status: No X-Spam-Status: No X-Spam-Flag: No X-Archives-Salt: 903ae2e3-b7d3-4c26-989a-d3afe3ba8fc7 X-Archives-Hash: 35c68fbdbe782e5f583e781e5e0ca83b On Tuesday, September 16, 2014 07:07:38 PM James wrote: > Hello, > > By now many are familiar with my keen interest in clustering gentoo > systems. So, what most cluster technologies use is a distributed file > system on top of the local (HD/SDD) file system. Naturally not > all file systems, particularly the distributed file systems, have > straightforward instructions. Also, an device file system, such as > XFS and a distibuted (on top of the device file system) combination > may not work very well when paired. So a variety of testing is > something I'm researching. Eliminiation of either file system > listed below, due to Gentoo User Experience is most welcome information, > as well as tips and tricks to setting up any file system. > > > Distributed File Systems (DFS): > HDFS (poor performance) > Lustre > Ceph > XtreemFS > GlusterFS > MooseFS > FhGFS (BeeGFS) soon to be entirely open sourced? > Any other distributed file systems I should consider using? > > Local (Device) File Systems LFS: > btrfs > zfs > ext4 > xfs > > Obviously I do not what to test all combinations of DFS/LocalFS > so your comments are extremely welcome as is any and all > related information. > > James James, Is my understanding correct that the top list all require one of the bottom list? Eg. the "clustering" FSs only ensure the files on the LFSs are duplicated/spread over the various nodes? I would normally expect the clustering FS to be either the full layer or a clustered block-device where an FS can be placed on top. Otherwise it seems more like a network filesystem with caching options (See AFS). I am also interested in these filesystems, but for a slightly different scenario: - 2 servers in remote locations (different offices) - 1 of these has all the files stored (server A) at the main office - The other (server B - remote office) needs to "offer" all files from serverA When server B needs to supply a file, it needs to check if the local copy is still the "valid" version. If yes, supply the local copy, otherwise download from server A. When a file is changed, server A needs to be updated. While server B is sharing a file, the file needs to be locked on server A preventing simultaneous updates. I prefer not to supply the same amount of storage at server B as server A has. The remote location generally only needs access to 5% of the total amount of files stored on server A. But not always the same 5%. Does anyone know of a filesystem that can handle this? -- Joost