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 149FF1381F3 for ; Thu, 3 Oct 2013 16:32:42 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 888F2E0B20; Thu, 3 Oct 2013 16:32:36 +0000 (UTC) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 5BA08E09C2 for ; Thu, 3 Oct 2013 16:32:35 +0000 (UTC) Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id DEF8C216E1 for ; Thu, 3 Oct 2013 12:32:34 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute6.internal (MEProxy); Thu, 03 Oct 2013 12:32:34 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.co.uk; h= message-id:date:from:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; s=mesmtp; bh=IFIpS4HNBVAYn2+vRLnYArcewd4=; b=USZ1u01++OSwyGn4yV/d58eJ8Klg Y4Y6yrrUGMNfylRvQRxmoVteIvuQxH9AwAgP2ZpMxKciZYcZniYQxDuZnfx/bb0m w/X537IgvfzSNgm8g/+Sg0gGECoJDIJsFDgHe+vhazhZAn9cQTUQrFzYcj9KBMqb OsjITevBM5sHb9c= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=IFIpS4HNBVAYn2+vRLnYAr cewd4=; b=NXFZoX03m0aHvI2MivuncY+OWy3kQFvRWqnvLQo97EmMj1GAt7WVqd n6qqTv//3Hj4lOi/gKj5f5oMUKFk9TDa2JSrQybGoQJIzoAqWFAonag0+8aTjc3J 7+FLRde+f9HLpEE5+dqjOhHS2c+S2QAVwZow9lpxo96ovGIwgybB4= X-Sasl-enc: rfrP3pCAK95o6TBWQwg0IX4tdIHt0il8G3WzzsyrqB5+ 1380817954 Received: from [192.168.1.100] (unknown [94.170.82.148]) by mail.messagingengine.com (Postfix) with ESMTPA id 79A8B6800A5 for ; Thu, 3 Oct 2013 12:32:34 -0400 (EDT) Message-ID: <524D9C17.8010901@fastmail.co.uk> Date: Thu, 03 Oct 2013 17:32:23 +0100 From: Kerin Millar User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; 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> In-Reply-To: <524D5E3C.6050809@googlemail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Archives-Salt: 48f8e4eb-aa5e-4ea1-ae90-575ca12fa132 X-Archives-Hash: 05361c6ced4c6519e19d5d8fd45226c3 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. > > tmpfs is the filesystem of choice for /tmp or /var/tmp/portage. --Kerin