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 A73311381F3 for ; Thu, 3 Oct 2013 18:50:40 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 739B4E0A8F; Thu, 3 Oct 2013 18:50:29 +0000 (UTC) Received: from mail-bk0-f49.google.com (mail-bk0-f49.google.com [209.85.214.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 445E8E0A5F for ; Thu, 3 Oct 2013 18:50:27 +0000 (UTC) Received: by mail-bk0-f49.google.com with SMTP id r7so1083676bkg.8 for ; Thu, 03 Oct 2013 11:50:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=VO4Q1ZciZFNXoxWZpUWNXiXrC9aJVPBlpqmzabXEEGw=; b=ovnUBm4fhowVPeekwb1m4Dcydt02Ttfo7lneMIu6g9PC9CIpnuJc6NiwAmHfQcnDxY 3ZS6ijxwc56UcBcvd0le+E77Har6Epf5CblSyefVdgqIQdiF0HPiOgZwlGDYdN3d0rnv 2TY/GgMZA+cwXB9Ft8fk2vlfL7shYhMTxan4DzE375YiYENJAC4r3bMSkpjm6a5GbIAC 7ewh9MTtRY1Zfh42oOhWob5LEr2xc5JNhnYtH+8UZdQ+BLfMTi4OKXbUJ7bMY7xrAAi6 4DQCf8f1Meu805wFOJB8KCOcNx+2/TY8nMqeZYuTXZkKc77Gw3dZQRUUij27Xc962nzQ w/Zg== X-Received: by 10.205.14.69 with SMTP id pp5mr9152771bkb.14.1380826226671; Thu, 03 Oct 2013 11:50:26 -0700 (PDT) Received: from [192.168.178.21] (p3E9E6EE7.dip0.t-ipconnect.de. [62.158.110.231]) by mx.google.com with ESMTPSA id on10sm5610813bkb.13.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 03 Oct 2013 11:50:26 -0700 (PDT) Message-ID: <524DBC72.6040406@googlemail.com> Date: Thu, 03 Oct 2013 20:50:26 +0200 From: Volker Armin Hemmann User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 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] which filesystem is more suitable for /var/tmp/portage? References: <5239A20E.7090102@ramses-pyramidenbau.de> <4083700.7YOtJyrB1G@wstn> <5239C231.9080702@gmail.com> <524D3F00.9090901@fastmail.co.uk> <524D5E3C.6050809@googlemail.com> <524D9C17.8010901@fastmail.co.uk> In-Reply-To: <524D9C17.8010901@fastmail.co.uk> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Archives-Salt: f7244853-8472-4ea4-8293-5c2166f9b525 X-Archives-Hash: aa7b449d652961d825cc5d6fae61513a Am 03.10.2013 18:32, schrieb Kerin Millar: > On 03/10/2013 13:08, Volker Armin Hemmann wrote: >> Am 03.10.2013 11:55, schrieb Kerin Millar: >>> On 18/09/2013 16:09, Alan McKinnon wrote: >>>> On 18/09/2013 16:05, Peter Humphrey wrote: >>>>> On Wednesday 18 Sep 2013 14:52:30 Ralf Ramsauer wrote: >>>>> >>>>>> In my opinion, reiser is a bit outdated ... >>>>> >>>>> What is the significance of its date? I use reiserfs on my Atom box >>>>> for /var, >>>>> /var/cache/squid and /usr/portage, and on my workstation for >>>>> /usr/portage and >>>>> /home/prh/.VirtualBox. It's never given me any trouble at all. >>>> >>>> >>>> Sooner or later, reiser is going to bitrot. The ReiserFS code itself >>>> will not change, but everything around it and what it plugs into will >>>> change. When that happens (not if - when), there is no-one to fix the >>>> bug and you will find yourself up the creek sans paddle >>>> >>>> An FS is not like a widget set, you can't really live with and >>>> workaround any defects that develop. When an FS needs patching, it >>>> needs >>>> patching, no ifs and buts. Reiser may nominally have a maintainer >>>> but in >>>> real terms there is effectively no-one >>>> >>>> Circumstances have caused ReiserFS to become a high-risk scenario and >>>> even though it might perform faultlessly right now, continued use >>>> should >>>> be evaluated in terms of that very real risk. >>> >>> Another problem with ReiserFS is its intrinsic dependency on the BKL >>> (big kernel lock). Aside from hampering scalability, it necessitated >>> compromise when the time came to eliminate the BKL: >> >> and that one was solved when - 4-5 years ago? > > Consider the manner in which the hard requirement on the BKL was > removed, then objectively argue that its "deep use of the specific > properties of the BKL" did not necessitate what would quite reasonably > be described as a compromise. > >> >>> >>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=8ebc423 >>> >>> >>> >>> Note the performance loss introduced by the patch; whether that was >>> addressed I do not know. >>> >>> In my view, ReiserFS is only useful for saving space through tail >>> packing. Unfortunately, tail packing makes it slower still (an issue >>> that was supposed to be resolved for good in Reiser4). >>> >> >> why don't you mention that reiserfs used barriers by default - and ext3 >> did not. Just to look good at 'using defaults benchmarks' (like >> phoronix)? I mean, if we are digging around in history.... and btrfs is >> still broken in my regards... > > Because none of this passive aggressive rhetoric would have had any > meaningful context within the content of my previous post. while your message had no meaningful context within this thread at all. Oh look, there was a data eating bug in XFS X years ago. Or oh look, some very heavy patching was done in ext4 over the time.... are just as meaning- and helpful as your message: not at all.