That must have been pre-ext2, so we will definitely need the exact date, the name of the site and archaeologist who dug up the evidence. lol!
On 2014-05-27 16:00, malcolmlewis wrote:
> But like you say, “If it ain’t broke, lets break it” to me are corner
> cases and can also send the the developers, bug handlers, packagers
> etc to IMHO a basically time wasting exercise which does no one any
> good.
>
> Having said that, if the concerned user provides solid details in their
> use case (rather than breaking because they can) in normal daily tasks
> that will (could?) benefit other users, then for sure spend time on it.
No, that is not so.
If a filesystem can break by simply writing files to it, then it is bad.
There is some flaw it it. Test suites stress systems in many ways, and
some times a chance test breaks a filesystem. Disregarding the fault
because it is difficult to solve, saying as excuse that it is a corner
case… That’s very lame, man. Sooner or later, those “corner cases”
will hit some expensive production system somewhere.
Or else, you have to specify in the documentation the usage parameters
in which the particular filesystem is valid, so that administrators make
sure that they don’t hit that breakage usage case, or use another type
of filesystem.
And actually, I remember the lead suse developer for btrfs asking us to
stress test btrfs and find the faults within. So I did… by chance,
not by intention.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
On 2014-05-27 19:46, consused wrote:
>
> robin_listas;2645779 Wrote:
>>> But neither of those file systems are the default file system. 
>>
>> Reiserfs was! At the time I crashed it. 
> That must have been pre-ext2, so we will definitely need the exact date,
> the name of the site and archaeologist who dug up the evidence. lol!
No, it was between ext2 and ext3. Certainly not before ext2, but after.
It was pre ext4.
IIRC, reiserfs was made the default filesystem on SuSE because the periodic filesystem check,
or the forced one after a forced powerdown, was very fast, as compared to ext2 which had no journal.
Then came ext3, with a journal (after they saw the reiserfs sucess). Ext3 was more resilient to failures,
after some polishing years (if reiserfs broke, it broke royally), but reiserfs was still much faster and efficient.
One criticism against SuSE at the time was that other distros did not even have reiserfs.
SuSE somehow boldly pioneered the field ahead of others. They have refused to repeat the experience,
so now they will not implement a filesystem that is not included in the upstream kernel (nor probably anything else).
Which is why we don’t have reiserfs4, I understand.
Quick search:
+++···············
Date: Thu, 31 Oct 2002 06:38:32 -0800
Subject: Re: [SLE] 8.1 - Kernel panic, install support non-existent
···············+±
They had to ask people to mount reiserfs with the option “barrier=none”, or the kernel could freeze. Later they issued a patched kernel update.
The name clash problem that I mentioned before was described first (AFAIK) in this other post:
+++···············
From: Uwe Debacher <>
Date: Tue, 03 Aug 2004 11:40:46 +0200
To: suse-security@suse.com
Subject: [suse-security] reiserfs strange behavior
Hi,
I have a strange problem with reiserfs and SuSE 9.1. There seem to be
pairs of filenames which are not different in the same directory.
An example is nb3001/mm3001:
/tmp> mkdir nb3001
/tmp> mkdir mm3001
mkdir: kann Verzeichnis „mm3001“ nicht anlegen: Die Datei existiert
bereits
/tmp> rm -r mm3001
> ls nb3001
/bin/ls: nb3001: Datei oder Verzeichnis nicht gefunden
This problem exists on any reiserfs partition an any of my SuSE 9.1
systems. If I change to ext3 everything is OK. Even reiserfs on SuSE 9.0
ist OK.
No matter whether you create files ore directories. ls always shows the
created file, but rm, chown, … may use both!
Some other pairs are bb3001/am3001 gb3001/fm3001 mb4001/lm4001.
Any hint where the problem or better the solution is?
···············+±
I read this post, and I had to try that. I created those directories… and hours later, I had to reformat the partition. Recovery was impossible. Since then, I’m very hesitant to test filesystems on real situations.
Go ahead, the list archives are public
You can find all that we said.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
extundelete is an interesting idea - I’ve heard of it before, but have never tried or heard anything (positive or negative) from some who has tried it before. ‘debuginfo’ and ‘debugsource’ seem to be in repos, but nothing else.
Aug 2013 isn’t the most recent testing that Phoronix has published. See this and this for hard disk and SSD tests respectively (both May 2014) tests.
In the test that you referenced, BTRFS ‘won’ a couple of the tests over EXT4, but only by trivial amounts. In contrast, Ext4 won some tests by significant amounts. There is no doubt that, in as much as this kind of testing indicates anything, it indicates a situation in which, in practice, Ext4 is going to prove the faster filesystem, where there is a worthwhile difference (although, I’ll also make the point that, given that the capabilities of BTRFS are more similar to ext4 plus LVM, there is a case for testing BTRFS against ext4 plus LVM, if those capabilities are relevant).
In the more recent hdd testing, the situation has changed. There is clearly something wrong with the AIO stress test on the Hard Disk Drive. Even a velociraptor isn’t that fast, actually, its interface isn’t that fast, never mind the mechanics of the drive. In the dbench - 1 client test, XFS is handily faster than either ext4 or BTRFS, but, in the 6 client test BTRFS is handily faster than the other two, with ext4 bringing up the rear from XFS by a small margin. The IOZone write test only has small margins, but BTRFS is fastest, followed by ext4 then XFS. TIOT random write 4/32M threads has BTRFS first then XFS then ext4. Postmark has relatively small margins, but the order is BTRFS top, then XFS them ext4.
Now, some of these tests will have such small margins that the differences won’t be apparent outside of properly instrumented benchmarking tests, but it isn’t a simple situation that one system is always fastest, another is always last: the real world is usually rather more messy than that and the results that you get are very heavily dependant on what *exactly *you measure.
There has been much discussion of the default file system. What hasn’t been discussed is that even having a single default filesystem goes counter to the latest recommendations (at least, that I’ve seen). In the Eckermann Linux Con 2013 paper, there is a flowchart presented (twice?) that has BTRFS, Ext4 and XFS as recommended filesystems for different usage scenarios. While you could conceive of something like an expert system or a simpler logic system that implemented Eckermann’s flowchart, plus the other recomendations (and, you could add ‘is your data really, really important to you?’ as a question, and if the answer is in the affirmative, disallow anything within 100 miles of experimental), I don’t think that’s about to happen.
- A notification system about lack of free space which informs even a non-technical User a critical event is imminent
Ahh, but who do you inform? The user or root? If the newb in question (and we are still assuming that this is a newb problem, but, in this case, that might not be the only possibility) has taken the advice to do all their work as an unprivileged user, telling root probably will do no good, or, at least, not sufficiently quickly for measures to be taken.
I think that you have probably heard the same info that I have that once a disk gets beyond some percentage full, the repair tools either don’t work or may as well not work. I don’t know whether this is still current information, and it would be worth checking that out. If it is, then the soft limit needs to be sufficiently low that there is time to delete a few snapshots before the situation becomes too critical to ever recover.
On 05/27/2014 01:45 PM, Carlos E. R. wrote:
> On 2014-05-27 19:46, consused wrote:
>>
>> robin_listas;2645779 Wrote:
>
>>>> But neither of those file systems are the default file system.
>>>
>>> Reiserfs was! At the time I crashed it.
>> That must have been pre-ext2, so we will definitely need the exact date,
>> the name of the site and archaeologist who dug up the evidence. lol!
>
>
>
> No, it was between ext2 and ext3. Certainly not before ext2, but after.
> It was pre ext4.
>
> IIRC, reiserfs was made the default filesystem on SuSE because the periodic filesystem check,
> or the forced one after a forced powerdown, was very fast, as compared to ext2 which had no journal.
> Then came ext3, with a journal (after they saw the reiserfs sucess). Ext3 was more resilient to failures,
> after some polishing years (if reiserfs broke, it broke royally), but reiserfs was still much faster and efficient.
>
> One criticism against SuSE at the time was that other distros did not even have reiserfs.
> SuSE somehow boldly pioneered the field ahead of others. They have refused to repeat the experience,
> so now they will not implement a filesystem that is not included in the upstream kernel (nor probably anything else).
> Which is why we don’t have reiserfs4, I understand.
Reiserfs4 was an unusual case. Hans Reiser refused to make the changes requested
by the kernel reviewers. That kept that fs out of the kernel. After his wife was
murdered, and he was convicted of the crime, that filesystem quietly disappeared.
Maybe I’m too young but I heard some wired things about reiserfs3 but that’s another story. However checking some forums, emails of the past the transition from ext2 => ext3 revealed that ext3 got declared as stable first in the kernel and the same goes for ext4 which is not the case for BTRFS. For users with experience and a good backup plan it’s not a big thing to go back but as soon average people are really using this FS and loosing data due to not carefully testing the reputation of BTRFS get punished and another thing is COW file systems need more ram as I have already noted the installer should take care of this. IMHO as long it’s not declared as stable in the kernel I think it should not be the default one and even it get used as the default one I will choose ext4 only for the simple reason: it’s too early and with LVM snapshots I would have the snapshot feature too.
Hmm. Before my time then, and I never ever used Reiserfs. My first was SUSE Linux 10.1, and I thought that had a default of ext2 (pretty sure I used ext2 then). I recall ext3 as default came to a release of “openSUSE” (10.x?) after that one.
On Tue, 27 May 2014 13:06:08 +0000, Ken Schneider wrote:
> “If it ain’t broke don’t fix it”
>
> and instead are of the mindset:
>
> “If it ain’t broke lets break it”
Or more along the lines of “we can leave everything alone and in 20 years
nothing will have changed, or we can make incremental improvements and
changes so we don’t get passed by.”
This is more the sort of thing that’s happening. And as resources move
from developing extXfs to btrfs, it makes sense to move the default
filesystem to the filesystem that’s got resources working on it.
Remember that OSS development is fluid and doesn’t stand still. If you
want to stand still, you should run Windows. 
Jim
Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C
On 05/27/2014 06:16 PM, Jim Henderson pecked at the keyboard and wrote:
> On Tue, 27 May 2014 13:06:08 +0000, Ken Schneider wrote:
>
>> “If it ain’t broke don’t fix it”
>>
>> and instead are of the mindset:
>>
>> “If it ain’t broke lets break it”
> Or more along the lines of “we can leave everything alone and in 20 years
> nothing will have changed, or we can make incremental improvements and
> changes so we don’t get passed by.”
Well, if it ain’t broke…
I’m all for moving to better ways of having a solid system. But I have
yet to hear if the problems have been fixed or repair programs have been
developed to fix problems that exist. Make the btrfs filesystem bullet
proof before making it the default for /.
My referral to let’s break it refers to having “new/better” technology
pushed as a default without full testing/stress testing. Can anyone
say KDE4 before it was usuable or the recent change to baloo before
there was enough feed back to resolve issues/problems?
> Remember that OSS development is fluid and doesn’t stand still. If you
> want to stand still, you should run Windows.
Great I just don’t want the “fluid” leaking on my system making it
unbootable making me spend unnecessary hours trying to fix it.
Ken
On Tue, 27 May 2014 23:19:28 +0000, Ken Schneider wrote:
> On 05/27/2014 06:16 PM, Jim Henderson pecked at the keyboard and wrote:
>> On Tue, 27 May 2014 13:06:08 +0000, Ken Schneider wrote:
>>
>>> “If it ain’t broke don’t fix it”
>>>
>>> and instead are of the mindset:
>>>
>>> “If it ain’t broke lets break it”
>> Or more along the lines of “we can leave everything alone and in 20
>> years nothing will have changed, or we can make incremental
>> improvements and changes so we don’t get passed by.”
>
> Well, if it ain’t broke…
>
> I’m all for moving to better ways of having a solid system. But I have
> yet to hear if the problems have been fixed or repair programs have been
> developed to fix problems that exist. Make the btrfs filesystem bullet
> proof before making it the default for /.
If you wait until it’s perfect, it never gets released. Software is /
never/ perfect. So you work to a point of “good enough” - and it seems
that the developers believe it has reached a point of “good enough”.
It’s always easy to look at a situation post-release and say “oh, that
should’ve been caught in testing” - but the ability to look back and say
“hey, that’s a scenario we should have tested for” isn’t something anyone
has at the time testing is done.
Everyone works with the best information they have at the time they have
it. Right now, it seems that the best information is that btrfs is good
enough for that purpose. The devs who work on it use it on their own
root filesystems for production work, I’m told (certainly the lead
developer does - I had a chat with him about that about a year ago).
> My referral to let’s break it refers to having “new/better” technology
> pushed as a default without full testing/stress testing.
And how much is enough, exactly? That’s the problem - “full” testing/
stress testing is a nebulous term. Is it not fully tested because …
what edge case hasn’t been tested to your satisfaction?
Maybe provide the testing team with those edge cases you think haven’t
been tested thoroughly enough. They can evaluate and add them to the
test suite.
It’s easy to criticize the testing done on a piece of software. It’s far
more difficult to provide some specific feedback on what seems deficient
in a way that can actually contribute to the testing.
> Can anyone
> say KDE4 before it was usuable or the recent change to baloo before
> there was enough feed back to resolve issues/problems?
Not really a fair comparison, or an apples-to-apples comparison. btrfs
has, to my understanding, been under development for significantly longer
than KDE4 was prior to its inclusion or baloo. I could be wrong about
that, but I don’t think I am.
>> Remember that OSS development is fluid and doesn’t stand still. If you
>> want to stand still, you should run Windows.
>
> Great I just don’t want the “fluid” leaking on my system making it
> unbootable making me spend unnecessary hours trying to fix it.
Nobody wants that, Ken. Least of all the developers who make a decision
to switch filesystems. You don’t think they care that if it doesn’t work
out that they’ll have egg on their face? I’d think about that again - I
think that there’s a certain amount of risk that they know they’re
taking, so they want to be sure that it works well.
Because if it doesn’t, there will be trouble from the community, and
rightfully so.
I think we need to give the developers some credit for knowing what an
appropriate risk to take is when it comes to data loss scenarios in a
filesystem selection. They do work with this stuff on a daily basis.
Jim
Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C
On Tue, 27 May 2014 23:37:34 +0000, Jim Henderson wrote:
>> I’m all for moving to better ways of having a solid system. But I have
>> yet to hear if the problems have been fixed or repair programs have
>> been developed to fix problems that exist.
I was going to link to the factory mailing list archives regarding this,
because there was a discussion with one the lead btrfs developer (Jeff
Mahoney) about this back in September - but I see you actually
participated in that thread, Ken…
http://lists.opensuse.org/opensuse-factory/2013-09/msg00029.html
Jim
–
Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C
On 05/27/2014 03:26 PM, consused wrote:
>
> robin_listas;2645803 Wrote:
>> On 2014-05-27 19:46, consused wrote:
>>>
>>> robin_listas;2645779 Wrote:
>>
>>>>> But neither of those file systems are the default file system.
>>>>
>>>> Reiserfs was! At the time I crashed it.
>>> That must have been pre-ext2, so we will definitely need the exact
>> date,
>>> the name of the site and archaeologist who dug up the evidence. lol!
>>
>>
>>
>> No, it was between ext2 and ext3. Certainly not before ext2, but after.
>> It was pre ext4.
>>
>> IIRC, reiserfs was made the default filesystem on SuSE…
> Hmm. Before my time then, and I never ever used Reiserfs. My first was
> SUSE Linux 10.1, and I thought that had a default of ext2 (pretty sure I
> used ext2 then). I recall ext3 as default came to a release of
> “openSUSE” (10.x?) after that one.
I first used SuSE in 2001 - I think it was 5.4. At that time, the file system
choices were ext2 and reiserfs3. Even though the disks were small, waiting
through fsck with ext2 after a crash or power failure was excruciating. As the
Linux box was the gateway/router and server for an entire room full of Windows
machines, I certainly did not want to expose any Linux weakness. Using reiserfs
solved that problem. What was even better was that the boss server machine was
available because it had too little power to run Windows 98!
On 2014-05-27 22:26, consused wrote:
>
> robin_listas;2645803 Wrote:
>> IIRC, reiserfs was made the default filesystem on SuSE…
> Hmm. Before my time then, and I never ever used Reiserfs. My first was
> SUSE Linux 10.1, and I thought that had a default of ext2 (pretty sure I
> used ext2 then). I recall ext3 as default came to a release of
> “openSUSE” (10.x?) after that one.
The wikipedia article on reiserfs mentions that “Jeff Mahoney of SUSE
wrote a post on Sep 14 2006 proposing to move from ReiserFS to ext3 for
the default installation file system”, that is, >= 10.2.
Strange that you used ext2 on 10.1, it was considered “obsolete” but
“reliable”. The default for 10.1 was still reiserfs (a good perfomance
alternative was root on a small ext2, the rest on xfs).
Reiserfs 3 has its problems nowdays (it has not been improved, rather it
is being let to quietly die), but there are some areas in which it is
still unsurpassed. It is an stupendous choice for maildir or nntp
storage, for instance.
In fact, the test I did on btrfs and which crashes it, was precisely a
test to verify if btrfs could take over in this particular niche. And it
failed…
So I keep waiting.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
On 2014-05-28 04:32, Larry Finger wrote:
> Even though the disks were small, waiting through fsck with ext2 after a
> crash or power failure was excruciating.
Indeed it was. Ans people looking over your shoulder murmuring about
“windows doesn’t do this, you know”
(which of course it did! LOL!)
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
On 2014-05-28 01:37, Jim Henderson wrote:
> Everyone works with the best information they have at the time they have
> it. Right now, it seems that the best information is that btrfs is good
> enough for that purpose. The devs who work on it use it on their own
> root filesystems for production work, I’m told (certainly the lead
> developer does - I had a chat with him about that about a year ago).
I know. And he confessed that he kept good and up to date backups
> Maybe provide the testing team with those edge cases you think haven’t
> been tested thoroughly enough. They can evaluate and add them to the
> test suite.
That’s what I did with mine. I’m still waiting…
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
On 2014-05-27 20:56, Obscurant wrote:
>
> tsu2;2645290 Wrote:
>> - A notification system about lack of free space which informs even a
>> non-technical User a critical event is imminent
>
> Ahh, but who do you inform? The user or root? If the newb in question
> (and we are still assuming that this is a newb problem, but, in this
> case, that might not be the only possibility) has taken the advice to do
> all their work as an unprivileged user, telling root probably will do no
> good, or, at least, not sufficiently quickly for measures to be taken.
In the traditional sense, Mr Root is informed by email, which in any
properly installed openSUSE system gets redirected to an specified plain
user.
Same as he gets informed of a raid failure, etc.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
Interesting perspective Larry, and understandable in the situation. Around that time I was enjoying Win95 (previously OS/2), on my home based pc where requirements were simpler. A few years later, after h/w failure and rebuild I tried Linux (testing with knoppix) then chose SUSE Linux (10.1) over Mandriva/Mandrake. For my situation, and reading general linux stuff, ext2 was still in common use and probably recommended as adequate for my needs. Very occasional power cuts never gave me a problem, even to this day although its ext4, btrfs, and more sophisticated h/w, with no power outage in the last couple of years.
That nails it close enough.
I can imagine within SUSE, but there were less cutting-edge views within Linux distros more generally, e.g. debian-based were more conservative, with user guides available on the internet, painting a different picture for a typical home computer. As a newcomer to Linux, but not to commercial IT, I new the value of KISS.
I still use ext2 for a small boot partition, as a good enough “performance alternative”, where “smart” and journalling are not required.
On 2014-05-27 21:14, Larry Finger wrote:
> On 05/27/2014 01:45 PM, Carlos E. R. wrote:
> Reiserfs4 was an unusual case. Hans Reiser refused to make the changes
> requested by the kernel reviewers. That kept that fs out of the kernel.
> After his wife was murdered, and he was convicted of the crime, that
> filesystem quietly disappeared.
Well, he went out of the picture, but his team kept working on it.
Slowly. Too slowly.
Interestingly, the wikipedia mentions that its current development is
funded by DARPA.
It is a pity, that R4 did not go forward…
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
On 2014-05-28 12:46, consused wrote:
>
> robin_listas;2645855 Wrote:
>> The wikipedia article on reiserfs mentions that “Jeff Mahoney of SUSE
>> wrote a post on Sep 14 2006 proposing to move from ReiserFS to ext3 for
>> the default installation file system”, that is, >= 10.2.
> That nails it close enough.
I remember the discussion that arose at the time. Big.
> robin_listas;2645855 Wrote:
>> Strange that you used ext2 on 10.1, it was considered “obsolete” but
>> “reliable”. The default for 10.1 was still reiserfs (a good perfomance
>> alternative was root on a small ext2, the rest on xfs).
> I can imagine within SUSE, but there were less cutting-edge views within
> Linux distros more generally, e.g. debian-based were more conservative,
> with user guides available on the internet, painting a different picture
> for a typical home computer.
Ah, yes, that’s true. It was basically SUSE which used reiserfs, not the
rest.
> I still use ext2 for a small boot partition, as a good enough
> “performance alternative”, where “smart” and journalling are not
> required.
Yes. me too. All my boot partitions are ext2.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)