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.
