From user-return-12711-apmail-couchdb-user-archive=couchdb.apache.org@couchdb.apache.org Thu Sep 16 19:48:01 2010 Return-Path: Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: (qmail 23094 invoked from network); 16 Sep 2010 19:48:00 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 16 Sep 2010 19:48:00 -0000 Received: (qmail 81384 invoked by uid 500); 16 Sep 2010 19:47:59 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 81327 invoked by uid 500); 16 Sep 2010 19:47:58 -0000 Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@couchdb.apache.org Delivered-To: mailing list user@couchdb.apache.org Received: (qmail 81319 invoked by uid 99); 16 Sep 2010 19:47:58 -0000 Received: from Unknown (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 16 Sep 2010 19:47:58 +0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of randall.leeds@gmail.com designates 209.85.214.52 as permitted sender) Received: from [209.85.214.52] (HELO mail-bw0-f52.google.com) (209.85.214.52) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 16 Sep 2010 19:47:35 +0000 Received: by bwz3 with SMTP id 3so2199585bwz.11 for ; Thu, 16 Sep 2010 12:47:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=ORSOnlm4GiZisUgqk7X9cdlJeqeVb18ea/6hM/H635g=; b=wdgkJdu+JCy/YrBvohsjqYEF/Rp8OnxoZsN84DSkUNLt8YeCmZDD+vP4RlroUIiVG9 mnNMVTTROZC7rbkF+a5WV1zhcCxTs58PR/L1cm0gS+GPXr832x2zcldBWZqNpZQMXSbE vDet6whWFowkR6floVqP53V6AfqhMhXbBs7rI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=Y1c/mjZDAwmaWOSP/92o0AcsvLGpBqu4nl6yEtMDyL96rxv+dBV1oMoKfhtzzGg9Gb n5oLt4ze3eYgbm0cW9ZKh2ytORB5RzaYWFYYddD2owbDFjRlItAdBXedd8O6tyPzLBai 6oV0zy2rtPC5xOlRt1/aeFypAEQ1OQc9iXDLo= MIME-Version: 1.0 Received: by 10.223.119.138 with SMTP id z10mr1673714faq.93.1284666435346; Thu, 16 Sep 2010 12:47:15 -0700 (PDT) Received: by 10.223.111.141 with HTTP; Thu, 16 Sep 2010 12:47:15 -0700 (PDT) In-Reply-To: References: Date: Thu, 16 Sep 2010 12:47:15 -0700 Message-ID: Subject: Re: Which filesystem is best for deploying couchdb and why? From: Randall Leeds To: user@couchdb.apache.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Virus-Checked: Checked by ClamAV on apache.org Disclaimer: I'm no file systems expert. I recommend something with extents otherwise you might take a big performance hit while couch deletes old db files after compaction. Compression sounds cool as long as you can do it really fast (are there setups where this happens in hardware?). reiserfs: According to wikipedia it "still uses the big kernel lock (BKL) =E2=80=94 a global kernel-wide lock" which makes performance on multiple cores suffer. It's big benefit, as I always understood it, is being able to pack smile files together into single blocks. You will likely not have lots of small files with Couch :-P xfs: Delayed allocation might be a big performance win with a Couch. Since outstanding writes are committed together in chunks and then fsync'd all together I bet this feature would do good things for Couch performance. ext(3|4) I'd recommend ext4 over ext3. Delayed allocation like xfs as well as the multiblock allocator should make it much better than ext3. You also get extents. btrfs/zfs: Some of the features of each sound interesting, but nothing that stands out to me as "great for CouchDB". Snapshots and backups are cool, but Couch is doing this for you already in a sense due to the way the btree is appended: CouchDB documents are, in a sense, copy-on-write. Checksumming is cool if you think it's important for your data integrity. If you want snapshots for backup you can always use CouchDB replication. If you run any tests I'd be very, very interested in seeing your results. -Randall On Thu, Sep 16, 2010 at 03:11, Metin Akat wrote: > I'm sure almost everybody out there is using ext4/3 (including me), > but what about filesystems like btrfs, zfs, reiserfs, xfs. Some of > them have very appealing feature-sets (like compression for example, > and we all know how greedy is couchdb for disk space). > And I know that for example btrfs is not yet "recommended for > production". But its time is coming. From what I see, Ubuntu 10.10 > works flawlessly on btrfs. > So I'd be happy if we have some discussion on the topic, instead of > "everybody uses ext4, just use it" kind of stuff :). > Couchdb was "alpha software" for years, and we all used it in > production, so we are not afraid of alpha/beta software, as long as > it's good :)