Re: [gentoo-user] which filesystem is more suitable for /var/tmp/portage?

[Volker Armin Hemmann <volkerarmin@googlemail.com>]

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.