Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Linux: Kernel

the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion

 

 

First page Previous page 1 2 3 4 5 6 7 8 9 Next page Last page  View All Linux kernel RSS feed   Index | Next | Previous | View Threaded


jbglaw at lug-owl

Jul 31, 2006, 11:36 AM

Post #151 of 223 (9878 views)
Permalink
Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion [In reply to]

On Mon, 2006-07-31 11:44:25 -0500, David Masover <ninja [at] slaphack> wrote:
> Jan-Benedict Glaw wrote:
> > On Mon, 2006-07-31 17:59:58 +0200, Adrian Ulrich
> > <reiser4 [at] blinkenlights> wrote:
> > > A colleague of mine happened to create a ~300gb filesystem and started
> > > to migrate Mailboxes (Maildir-style format = many small files (1-3kb))
> > > to the new LUN. At about 70% the filesystem ran out of inodes; Not a
> >
> > So preparation work wasn't done.
>
> Let me put it this way -- You're back in college, and it's time to write
> a thesis. You have a choice of software packages:
>
> Package A: You have to specify how many pages, and how many words,
> you're likely to use before you start typing. Guess too high, and
> you'll print out a bunch of blank pages at the end. Guess too low, and
> you'll run out of space and have to start over, copy and paste your
> document back in, and hope it gets all the formatting right, which it
> probably won't.
>
> Package B: Your document grows as you type. When it's time to print,
> only the pages you've actually written something on -- but all of the
> pages you've actually written something on -- are printed.
>
> All other things being equal, which would you choose? Which one seems
> more modern?

:) Well, given that TeX needs two (or even three!) runs to get all
page references right, why should I choose MS Word, where you won't
see that problem at all?

MfG, JBG

--
Jan-Benedict Glaw jbglaw [at] lug-owl +49-172-7608481
Signature of: If it doesn't work, force it.
the second : If it breaks, it needed replacing anyway.
Attachments: signature.asc (0.18 KB)


jbglaw at lug-owl

Jul 31, 2006, 11:43 AM

Post #152 of 223 (9855 views)
Permalink
Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion [In reply to]

On Mon, 2006-07-31 20:11:20 +0200, Matthias Andree <matthias.andree [at] gmx> wrote:
> Jan-Benedict Glaw schrieb am 2006-07-31:
> > * reiser3: A HDD containing a reiser3 filesystem was tried to be
> > booted on a machine that fucked up DMA writes. Fortunately, it
> > crashed really soon (right after going for read-write.) After
> > rebooting the HDD on a sane PeeCee, it refused to boot. Starting
> > off some rescue system showed an _empty_ root filesystem.
>
> Massive hardware problems don't count. ext2/ext3 doesn't look much better in
> such cases. I had a machine with RAM gone bad (no ECC - I wonder what

They do! Very much, actually. These happen In Real Life, so I have to
pay attention to them. Once you're in setups with > 10000 machines,
everything counts. At some certain point, you can even use HDD's
temperature sensors in old machines to diagnose dead fans.

Everything that eases recovery for whatever reason is something you
have to pay attention to. The simplicity of ext{2,3} is something I
really fail to find proper words for. As well as the really good fsck.
Once seen a SIGSEGV'ing fsck, you really don't want to go there.

MfG, JBG

--
Jan-Benedict Glaw jbglaw [at] lug-owl +49-172-7608481
Signature of: Eine Freie Meinung in einem Freien Kopf
the second : für einen Freien Staat voll Freier Bürger.
Attachments: signature.asc (0.18 KB)


clay.barnes at gmail

Jul 31, 2006, 12:17 PM

Post #153 of 223 (9867 views)
Permalink
Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion [In reply to]

On 20:43 Mon 31 Jul , Jan-Benedict Glaw wrote:
> On Mon, 2006-07-31 20:11:20 +0200, Matthias Andree <matthias.andree [at] gmx> wrote:
> > Jan-Benedict Glaw schrieb am 2006-07-31:
> > > * reiser3: A HDD containing a reiser3 filesystem was tried to be
> > > booted on a machine that fucked up DMA writes. Fortunately, it
> > > crashed really soon (right after going for read-write.) After
> > > rebooting the HDD on a sane PeeCee, it refused to boot. Starting
> > > off some rescue system showed an _empty_ root filesystem.
> >
> > Massive hardware problems don't count. ext2/ext3 doesn't look much better in
> > such cases. I had a machine with RAM gone bad (no ECC - I wonder what
>
> They do! Very much, actually. These happen In Real Life, so I have to
> pay attention to them. Once you're in setups with > 10000 machines,
> everything counts. At some certain point, you can even use HDD's
> temperature sensors in old machines to diagnose dead fans.

I think what he meant was that it is unfair to blame reiser3 for data
loss in a massive failure situation as a case example by itself. What
would be more appropriate (and fair) is saying something along the lines
of "in a machine with DMA failure, reiser3 hosed a drive, while ext3
only lost x data (or nothing). In my situation, every bit of massive
failure robustness counts... " This of course assumes you actually had
the *exact* same problem with hardware under ext3, pretty much in every
detail. Of course, so many subtleties interact in massive ways with
filesystems and hardware problems, so we have to keep in mind how much
difference that can make (all the difference in the world), and that,
really, without a statistically significant sample size and some real
analysis, hardware failure comparisons are impossible to do fairly.

Of course, if ext3 were proven to be more robust against failures, I bet
the reiser team would be very interested in all the forensic data you
can offer, since, from what I've seen, they are always trying to make
reiser as good as possible---in speed, flexability, *and* robustness.
If they didn't care about the last, they'd benifit greatly from not
journaling! :-P

--Clay
>
> Everything that eases recovery for whatever reason is something you
> have to pay attention to. The simplicity of ext{2,3} is something I
> really fail to find proper words for. As well as the really good fsck.
> Once seen a SIGSEGV'ing fsck, you really don't want to go there.
>
> MfG, JBG
>
> --
> Jan-Benedict Glaw jbglaw [at] lug-owl +49-172-7608481
> Signature of: Eine Freie Meinung in einem Freien Kopf
> the second : fr einen Freien Staat voll Freier Brger.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


jbglaw at lug-owl

Jul 31, 2006, 12:29 PM

Post #154 of 223 (9858 views)
Permalink
Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion [In reply to]

On Mon, 2006-07-31 12:17:12 -0700, Clay Barnes <clay.barnes [at] gmail> wrote:
> On 20:43 Mon 31 Jul , Jan-Benedict Glaw wrote:
> > On Mon, 2006-07-31 20:11:20 +0200, Matthias Andree <matthias.andree [at] gmx> wrote:
> > > Jan-Benedict Glaw schrieb am 2006-07-31:
[Crippled DMA writes]
> > > Massive hardware problems don't count. ext2/ext3 doesn't look much better in
> > > such cases. I had a machine with RAM gone bad (no ECC - I wonder what
> >
> > They do! Very much, actually. These happen In Real Life, so I have to
>
> I think what he meant was that it is unfair to blame reiser3 for data
> loss in a massive failure situation as a case example by itself. What

Crippling a few KB of metadata in the ext{2,3} case probably wouldn't
fobar the filesystem...

> failure robustness counts... " This of course assumes you actually had
> the *exact* same problem with hardware under ext3, pretty much in every
> detail. Of course, so many subtleties interact in massive ways with

The point is that it's quite hard to really fuck up ext{2,3} with only
some KB being written while it seems (due to the
fragile^Wsophisticated on-disk data structures) that it's just easy to
kill a reiser3 filesystem.

MfG, JBG

--
Jan-Benedict Glaw jbglaw [at] lug-owl +49-172-7608481
Signature of: Zensur im Internet? Nein danke!
the second :
Attachments: signature.asc (0.18 KB)


clay.barnes at gmail

Jul 31, 2006, 12:34 PM

Post #155 of 223 (9873 views)
Permalink
Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion [In reply to]

On 20:42 Mon 31 Jul , Alan Cox wrote:
> Ar Llu, 2006-07-31 am 12:17 -0700, ysgrifennodd Clay Barnes:
> > Of course, if ext3 were proven to be more robust against failures, I bet
> > the reiser team would be very interested in all the forensic data you
> > can offer, since, from what I've seen, they are always trying to make
> > reiser as good as possible---in speed, flexability, *and* robustness.
>
> Its well accepted that reiserfs3 has some robustness problems in the
> face of physical media errors. The structure of the file system and the
> tree basis make it very hard to avoid such problems. XFS appears to have
> managed to achieve both robustness and better data structures.

Yes, that is true, and I think that's a big motivator for the reiser
team to get reiser4 in a place where people can't say that. I suspect
that they know that reiserfs's shortcomings in that respect are probably
the biggest deterrent to using that fs, and they'll do everything they
can to prevent such a problem in reiser4. That's pure conjecture based
on the stuff I see on the list, so if I'm wrong, reiser people, please
correct me.

--Clay

>
> How reiser4 compares I've no idea.
>
> Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


tytso at mit

Jul 31, 2006, 12:41 PM

Post #156 of 223 (9849 views)
Permalink
Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion [In reply to]

On Mon, Jul 31, 2006 at 06:54:06PM +0200, Matthias Andree wrote:
> > > This looks rather like an education issue rather than a technical limit.
> >
> > We aren't talking about the same issue: I was asking to do it
> > on-the-fly. Umounting the filesystem, running e2fsck and resize2fs
> > is something different ;-)
>
> There was stuff by Andreas Dilger, to support "online" resizing of
> mounted ext2 file systems. I never cared to look for this (does it
> support ext3, does it work with current kernels, merge status) since
> offline resizing was always sufficient for me.

With the latest e2fsprogs and 2.6 kernels, the online resizing support
has been merged in, and as long as the filesystem was created with
space reserved for growing the filesystem (which is now the default,
or if the filesystem has the off-line prepration step ext2prepare run
on it), you can run resize2fs on a mounted filesystem and grow an
ext2/3 filesystem on-line. And yes, you get more inodes as you add
more disk blocks, using the original inode ratio that was established
when the filesystem was created.

- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


alan at lxorguk

Jul 31, 2006, 12:42 PM

Post #157 of 223 (9863 views)
Permalink
Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion [In reply to]

Ar Llu, 2006-07-31 am 12:17 -0700, ysgrifennodd Clay Barnes:
> Of course, if ext3 were proven to be more robust against failures, I bet
> the reiser team would be very interested in all the forensic data you
> can offer, since, from what I've seen, they are always trying to make
> reiser as good as possible---in speed, flexability, *and* robustness.

Its well accepted that reiserfs3 has some robustness problems in the
face of physical media errors. The structure of the file system and the
tree basis make it very hard to avoid such problems. XFS appears to have
managed to achieve both robustness and better data structures.

How reiser4 compares I've no idea.

Alan

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


ninja at slaphack

Jul 31, 2006, 1:00 PM

Post #158 of 223 (9870 views)
Permalink
Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion [In reply to]

Jan-Benedict Glaw wrote:
> On Mon, 2006-07-31 12:17:12 -0700, Clay Barnes <clay.barnes [at] gmail> wrote:
>> On 20:43 Mon 31 Jul , Jan-Benedict Glaw wrote:
>>> On Mon, 2006-07-31 20:11:20 +0200, Matthias Andree <matthias.andree [at] gmx> wrote:
>>>> Jan-Benedict Glaw schrieb am 2006-07-31:
> [Crippled DMA writes]
>>>> Massive hardware problems don't count. ext2/ext3 doesn't look much better in
>>>> such cases. I had a machine with RAM gone bad (no ECC - I wonder what
>>> They do! Very much, actually. These happen In Real Life, so I have to
>> I think what he meant was that it is unfair to blame reiser3 for data
>> loss in a massive failure situation as a case example by itself. What
>
> Crippling a few KB of metadata in the ext{2,3} case probably wouldn't
> fobar the filesystem...

Probably. By the time a few KB of metadata are corrupted, I'm reaching
for my backup. I don't care what filesystem it is or how easy it is to
edit the on-disk structures.

This isn't to say that having robust on-disk structures isn't a good
thing. I have no idea how Reiser4 will hold up either way. But
ultimately, what you want is the journaling (so power failure / crashes
still leave you in an OK state), backups (so when blocks go bad, you
don't care), and performance (so you can spend less money on hardware
and more money on backup hardware).
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


matthias.andree at gmx

Jul 31, 2006, 1:07 PM

Post #159 of 223 (9860 views)
Permalink
Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion [In reply to]

Adrian Ulrich schrieb am 2006-07-31:

> Ehr: Such a migration (on a very busy system) takes *some* time (weeks).
> Re-Doing (migrate users back / recreate the FS / start again) the whole
> thing isn't really an option..

All the more important to think about FS requirements *before*
newfs-ing if a quick "one day for rsync/star/dump+restore" isn't
available. If you're hitting, for instance, the hash collision problem
in reiser3, you're as dead as with a FS without inodes.

> > > Have you ever seen VxFS or WAFL in action?
> >
> > No I haven't. As long as they are commercial, it's not likely that I
> > will.
>
> Why?

I'm trying to shift my focus away from computer administration and
better file systems than old-style non-journalling, non-softupdates UFS
are available today and more will follow.

Cc: list weeded out.

--
Matthias Andree
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


reiser4 at blinkenlights

Jul 31, 2006, 1:32 PM

Post #160 of 223 (9867 views)
Permalink
Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion [In reply to]

> All the more important to think about FS requirements *before*
> newfs-ing if a quick "one day for rsync/star/dump+restore" isn't
> available. If you're hitting, for instance, the hash collision problem
> in reiser3, you're as dead as with a FS without inodes.

Quoting myself:
>> Let's face it: Shit happens and nobody is perfect. A filesystem should
>> be flexible (modern..) and support Admin/User-needs.

Of COURSE you should think BEFORE creating the filesystem.
But if you somehow failed to do it 'the right thing' your filesystem
shouldn't let you down.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


dlang at digitalinsight

Jul 31, 2006, 1:53 PM

Post #161 of 223 (9863 views)
Permalink
Re: the " 'official' point of view" expressed by kernelnewbies.orgregarding reiser4 inclusion [In reply to]

On Mon, 31 Jul 2006, David Masover wrote:

> Probably. By the time a few KB of metadata are corrupted, I'm reaching for
> my backup. I don't care what filesystem it is or how easy it is to edit the
> on-disk structures.
>
> This isn't to say that having robust on-disk structures isn't a good thing.
> I have no idea how Reiser4 will hold up either way. But ultimately, what you
> want is the journaling (so power failure / crashes still leave you in an OK
> state), backups (so when blocks go bad, you don't care), and performance (so
> you can spend less money on hardware and more money on backup hardware).

please read the discussion that took place at the filesystem summit a couple
weeks ago (available on lwn.net)

one of the things that they pointed out there is that as disks get larger the
ratio of bad spots per Gig of storage is remaining about the same. As is the
rate of failures per Gig of storage.

As a result of this the idea of only running on perfect disks that never have
any failures is becomeing significantly less realistic, instead you need to take
measures to survive in the face of minor corruption (including robust
filesystems, raid, etc)

David Lang
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


gmaxwell at gmail

Jul 31, 2006, 2:00 PM

Post #162 of 223 (9863 views)
Permalink
Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion [In reply to]

On 7/31/06, Alan Cox <alan [at] lxorguk> wrote:
> Its well accepted that reiserfs3 has some robustness problems in the
> face of physical media errors. The structure of the file system and the
> tree basis make it very hard to avoid such problems. XFS appears to have
> managed to achieve both robustness and better data structures.
>
> How reiser4 compares I've no idea.

Citation?

I ask because your clam differs from the only detailed research that
I'm aware of on the subject[1]. In figure 2 of the iron filesystems
paper that Ext3 is show to ignore a great number of data-loss inducing
failure conditions that Reiser3 detects an panics under.

Are you sure that you aren't commenting on cases where Reiser3 alerts
the user to a critical data condition (via a panic) which leads to a
trouble report while ext3 ignores the problem which suppresses the
trouble report from the user?

*1) http://www.cs.wisc.edu/adsl/Publications/iron-sosp05.pdf
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


bernd-schubert at gmx

Jul 31, 2006, 2:14 PM

Post #163 of 223 (9849 views)
Permalink
Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion [In reply to]

On Monday 31 July 2006 21:29, Jan-Benedict Glaw wrote:
>
> The point is that it's quite hard to really fuck up ext{2,3} with only
> some KB being written while it seems (due to the
> fragile^Wsophisticated on-disk data structures) that it's just easy to
> kill a reiser3 filesystem.
>

Well, I was once very 'luckily' and after a system crash (*) e2fsck put all
files into lost+found. Sure, I never experienced this again, but I also never
experienced something like this with reiserfs. So please, stop this kind of
FUD against reiser3.6.
While filesystem speed is nice, it also would be great if reiser4.x would be
very robust against any kind of hardware failures.

(*) The problem was a specific mainboard + video-card + driver combination. As
soon as X started up, the system entirely crashed. I don't believe many bytes
were written, but I also can't prove it.

--
Bernd Schubert
PCI / Theoretische Chemie
Universitt Heidelberg
INF 229
69120 Heidelberg

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


ninja at slaphack

Jul 31, 2006, 2:16 PM

Post #164 of 223 (9863 views)
Permalink
Re: the " 'official' point of view" expressed by kernelnewbies.orgregarding reiser4 inclusion [In reply to]

David Lang wrote:
> On Mon, 31 Jul 2006, David Masover wrote:
>
>> Probably. By the time a few KB of metadata are corrupted, I'm
>> reaching for my backup. I don't care what filesystem it is or how
>> easy it is to edit the on-disk structures.
>>
>> This isn't to say that having robust on-disk structures isn't a good
>> thing. I have no idea how Reiser4 will hold up either way. But
>> ultimately, what you want is the journaling (so power failure /
>> crashes still leave you in an OK state), backups (so when blocks go
>> bad, you don't care), and performance (so you can spend less money on
>> hardware and more money on backup hardware).
>
> please read the discussion that took place at the filesystem summit a
> couple weeks ago (available on lwn.net)

I think I will, but I don't have the time today, so...

> one of the things that they pointed out there is that as disks get
> larger the ratio of bad spots per Gig of storage is remaining about the
> same. As is the rate of failures per Gig of storage.
>
> As a result of this the idea of only running on perfect disks that never
> have any failures is becomeing significantly less realistic, instead you
> need to take measures to survive in the face of minor corruption
> (including robust filesystems, raid, etc)

RAID seems a much more viable solution to me. That and cheaper storage,
so that you can actually afford to replace the disk when you find
corruption, or have more redundancy so you don't have to.

Because "robust filesystems" is nice in theory, but in practice, you
really never know what will get hit. RAID, at least, is predictable.

When it's not: Backups.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


prymitive at pcserwis

Jul 31, 2006, 2:21 PM

Post #165 of 223 (9874 views)
Permalink
Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion [In reply to]

Dnia Mon, 31 Jul 2006 19:32:39 +0200, Jan-Benedict Glaw
<jbglaw [at] lug-owl> napisa:

> On Mon, 2006-07-31 18:44:33 +0200, Rudy Zijlstra <rudy [at] edsons>
> wrote:
>> On Mon, 31 Jul 2006, Jan-Benedict Glaw wrote:
>> > On Mon, 2006-07-31 17:59:58 +0200, Adrian Ulrich
>> > <reiser4 [at] blinkenlights> wrote:
>> > > A colleague of mine happened to create a ~300gb filesystem and
>> started
>> > > to migrate Mailboxes (Maildir-style format = many small files
>> (1-3kb))
>> > > to the new LUN. At about 70% the filesystem ran out of inodes; Not a
>> >
>> > So preparation work wasn't done.
>>
>> Of course you are right. Preparation work was not fully done. And using
>> ext1 would also have been possible. I suspect you are still using ext1,
>> cause with proper preparation it is perfectly usable.
>
> Oh, and before people start laughing at me, here are some personal or
> friend's experiences with different filesystems:
>
> * reiser3: A HDD containing a reiser3 filesystem was tried to be
> booted on a machine that fucked up DMA writes. Fortunately, it
> crashed really soon (right after going for read-write.) After
> rebooting the HDD on a sane PeeCee, it refused to boot. Starting
> off some rescue system showed an _empty_ root filesystem.
>
> * A friend's XFS data partition (portable USB/FireWire HDD) once
> crashed due to being hot-unplugged off the USB. The in-kernel XFS
> driver refused to mount that thing again, and the tools also
> refused to fix any errors. (Don't ask, no details at my hands...)
>
> * JFS just always worked for me. Though I've never ever had a broken
> HDD where it (or it's tools) could have shown how well-done they
> were, so from a crash-recovery point of view, it's untested.
>
> * Being a regular ext3 user, I had lots of broken HDDs containing
> ext3 filesystems. For every single case, it has been easy fixing
> the filesystem after cloning. Just _once_, fsck wasn't able to fix
> something, so I did it manually with some disk editor. This worked
> well because the on-disk data structures are actually as simple as
> they are.

Is this some kind of "who lost more files on what fs" competition? What's
the prize?
Topic subject sugests that it should cover something else. Please, let's
get back on track.
First of all, it's about reiser4 so can't we forget about other
filesystem's unless it's got something to do with reiser4 merge?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


alan at lxorguk

Jul 31, 2006, 2:40 PM

Post #166 of 223 (9868 views)
Permalink
Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion [In reply to]

Ar Llu, 2006-07-31 am 17:00 -0400, ysgrifennodd Gregory Maxwell:
> On 7/31/06, Alan Cox <alan [at] lxorguk> wrote:
> > Its well accepted that reiserfs3 has some robustness problems in the
> > face of physical media errors. The structure of the file system and the
> > tree basis make it very hard to avoid such problems. XFS appears to have
> > managed to achieve both robustness and better data structures.
> >
> > How reiser4 compares I've no idea.
>
> Citation?

Two sources, the cases I've looked at myself when IDE maintainer and
also comments Hans made when we met at UKUUG a few years ago. Generally
speaking on an IDE failure that lost chunks of disk the ext2/ext3 users
got most of their data back. The reiserfs ones sometimes got it back and
sometimes got catastrophic failure.

The ext3 fsck is extremely effective in the face of serious errors. Some
of that is clever code that knows about things like rewriting inode
blocks to force reallocation of failed metadata by the drive but the
majority of it is simply because you *know* where inode X is on the disk
rather than having to deal with data structures and walk them.

That's a tradeoff with the reiser performance with small files and until
recently the reiser large directory performance. Which is right is
another question altogether. Its also something I think XFS demonstrates
can be done better so doesn't invalidate the theory behind reiserfs just
the rev 3 implementation.

> Are you sure that you aren't commenting on cases where Reiser3 alerts
> the user to a critical data condition (via a panic) which leads to a
> trouble report while ext3 ignores the problem which suppresses the
> trouble report from the user?

man mount

Ext3 is configurable, and has been for years via the errors= option.

Alan

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


ninja at slaphack

Jul 31, 2006, 2:43 PM

Post #167 of 223 (9861 views)
Permalink
Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion [In reply to]

Alan Cox wrote:
> Ar Llu, 2006-07-31 am 17:00 -0400, ysgrifennodd Gregory Maxwell:

>> Are you sure that you aren't commenting on cases where Reiser3 alerts
>> the user to a critical data condition (via a panic) which leads to a
>> trouble report while ext3 ignores the problem which suppresses the
>> trouble report from the user?
>
> man mount
>
> Ext3 is configurable, and has been for years via the errors= option.

Sure, but I think the suggestion is that the reason we generally see
more ReiserFS complaints than ext3 complaints might be because of the
default level of errors logged.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


jmerkey at wolfmountaingroup

Jul 31, 2006, 2:54 PM

Post #168 of 223 (9948 views)
Permalink
Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion [In reply to]

Gregory Maxwell wrote:

> On 7/31/06, Alan Cox <alan [at] lxorguk> wrote:
>
>> Its well accepted that reiserfs3 has some robustness problems in the
>> face of physical media errors. The structure of the file system and the
>> tree basis make it very hard to avoid such problems. XFS appears to have
>> managed to achieve both robustness and better data structures.
>>
>> How reiser4 compares I've no idea.
>
>
> Citation?
>
> I ask because your clam differs from the only detailed research that
> I'm aware of on the subject[1]. In figure 2 of the iron filesystems
> paper that Ext3 is show to ignore a great number of data-loss inducing
> failure conditions that Reiser3 detects an panics under.
>
> Are you sure that you aren't commenting on cases where Reiser3 alerts
> the user to a critical data condition (via a panic) which leads to a
> trouble report while ext3 ignores the problem which suppresses the
> trouble report from the user?
>
> *1) http://www.cs.wisc.edu/adsl/Publications/iron-sosp05.pdf

Hi Gregory, Wikimedia Foundation and LKML?

How's Wikimania going. :-)

What he says is correct. I have seen some serious issues with reiserfs
in terms of stability and
data corruption. Resier is however FASTER, but the statement is has
robustness issues is accurate.
I was using reiserfs but we opted to make EXT3 the default for Solera
appliances, even when using Suse 10
due to issues I have seen with data corruption and hard hangs on RAID 0
read/write sector errors. I have
stopped using it for local drives and based everything on EXT3. Not to
say it won't get there eventually, but
file systems have to endure a lot of time in the field and deployment
befor they are ready for prime time.

The Wikimedia appliances use Wolf Mountain, and I've tested it for about
4 months with few problems, but
I only use it for hosting the Cherokee Langauge Wikipedia. It's
performance is several magnitudes better
than either EXT3 or ReiserFS. Despite this, for vertical wiki servers,
its ok to go out with, folks can specifiy
whether they want appliances with EXT3, Reiser, or WMFS, but iit's a
long way from being "cooked"
completely, though it does scale to 1 exabyte FS images.

Reiser does have issues still, and I hestitate to standardize on it
until I stop seeing reports from the field about
corruption and failover issues.

Jeff

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


jmerkey at wolfmountaingroup

Jul 31, 2006, 3:02 PM

Post #169 of 223 (9855 views)
Permalink
Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion [In reply to]

Jeff V. Merkey wrote:

> Gregory Maxwell wrote:
>
>> On 7/31/06, Alan Cox <alan [at] lxorguk> wrote:
>>
>>> Its well accepted that reiserfs3 has some robustness problems in the
>>> face of physical media errors. The structure of the file system and the
>>> tree basis make it very hard to avoid such problems. XFS appears to
>>> have
>>> managed to achieve both robustness and better data structures.
>>>
>>> How reiser4 compares I've no idea.
>>
>>
>>
>> Citation?
>>
>> I ask because your clam differs from the only detailed research that
>> I'm aware of on the subject[1]. In figure 2 of the iron filesystems
>> paper that Ext3 is show to ignore a great number of data-loss inducing
>> failure conditions that Reiser3 detects an panics under.
>>
>> Are you sure that you aren't commenting on cases where Reiser3 alerts
>> the user to a critical data condition (via a panic) which leads to a
>> trouble report while ext3 ignores the problem which suppresses the
>> trouble report from the user?
>>
>> *1) http://www.cs.wisc.edu/adsl/Publications/iron-sosp05.pdf
>
>
> Hi Gregory, Wikimedia Foundation and LKML?
> How's Wikimania going. :-)
>
> What he says is correct. I have seen some serious issues with
> reiserfs in terms of stability and
> data corruption. Resier is however FASTER, but the statement is has
> robustness issues is accurate.
> I was using reiserfs but we opted to make EXT3 the default for Solera
> appliances, even when using Suse 10
> due to issues I have seen with data corruption and hard hangs on RAID
> 0 read/write sector errors. I have
> stopped using it for local drives and based everything on EXT3. Not
> to say it won't get there eventually, but
> file systems have to endure a lot of time in the field and deployment
> befor they are ready for prime time.
>

Correction,

That's "MediWiki" appliances. Two many transposed acronyms...

www.wolfmountaingroup.com

:-)

Jeff

> The Wikimedia appliances use Wolf Mountain, and I've tested it for
> about 4 months with few problems, but
> I only use it for hosting the Cherokee Langauge Wikipedia. It's
> performance is several magnitudes better
> than either EXT3 or ReiserFS. Despite this, for vertical wiki
> servers, its ok to go out with, folks can specifiy
> whether they want appliances with EXT3, Reiser, or WMFS, but iit's a
> long way from being "cooked"
> completely, though it does scale to 1 exabyte FS images.
> Reiser does have issues still, and I hestitate to standardize on it
> until I stop seeing reports from the field about
> corruption and failover issues.
>
> Jeff
>
> -
> To unsubscribe from this list: send the line "unsubscribe
> linux-kernel" in
> the body of a message to majordomo [at] vger
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


matthias.andree at gmx

Jul 31, 2006, 3:17 PM

Post #170 of 223 (9852 views)
Permalink
Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion [In reply to]

Jan-Benedict Glaw schrieb am 2006-07-31:

> > Massive hardware problems don't count. ext2/ext3 doesn't look much better in
> > such cases. I had a machine with RAM gone bad (no ECC - I wonder what
>
> They do! Very much, actually. These happen In Real Life, so I have to
> pay attention to them. Once you're in setups with > 10000 machines,
> everything counts. At some certain point, you can even use HDD's
> temperature sensors in old machines to diagnose dead fans.
>
> Everything that eases recovery for whatever reason is something you
> have to pay attention to. The simplicity of ext{2,3} is something I
> really fail to find proper words for. As well as the really good fsck.
> Once seen a SIGSEGV'ing fsck, you really don't want to go there.

The point is: If you've written data with broken hardware (RAM, bus,
controllers - loads of them, CPU), what is on your disks is
untrustworthy anyways, and fsck isn't going to repair your gzip file
where every 64th bit has become a 1 or when the battery-backed write
cache threw 60 MB down the drain...

Of course, an fsck that crashes is unbearable, but that doesn't apply to
"broken hardware" failures. You need backups with a few generations to
avoid massively losing data.

--
Matthias Andree
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


jmerkey at wolfmountaingroup

Jul 31, 2006, 3:21 PM

Post #171 of 223 (9856 views)
Permalink
Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion [In reply to]

>
> Correction,
>
> That's "MediWiki" appliances. Two many transposed acronyms...
>
> www.wolfmountaingroup.com
>
> :-)
>
> Jeff
>
And WMFS does not belong to the WolfMountainGroup any longer. It has
been acquired by another company, so you won't see any info
about it on the website. It's has been rolled into another company. I
can bundle it with appliances but it is no longer the property of
Wolf Mountain Group. WMG is a MediaWiki/Wikipedia Appliance company
that does Machine translations of Wikipedia into several
Native American Languages. The Translator is Linux and Windows based,
but WMFS has a new home now.

Just to clarify.

Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


matthias.andree at gmx

Jul 31, 2006, 3:53 PM

Post #172 of 223 (9867 views)
Permalink
Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion [In reply to]

Theodore Tso schrieb am 2006-07-31:

> With the latest e2fsprogs and 2.6 kernels, the online resizing support
> has been merged in, and as long as the filesystem was created with
> space reserved for growing the filesystem (which is now the default,
> or if the filesystem has the off-line prepration step ext2prepare run
> on it), you can run resize2fs on a mounted filesystem and grow an
> ext2/3 filesystem on-line. And yes, you get more inodes as you add
> more disk blocks, using the original inode ratio that was established
> when the filesystem was created.

That's cool.

The interesting part for some people would be, if I read past postings
correctly, to change the inode ratio in an existing (perhaps even
mounted) file system without losing data.

(I'm not sure how many blocks have to be moved and/or changed for that
purpose, because I know too little about the on-disk ext2 layout, but
since block relocating is already in place for shrink support in the
offline resizer, some of the work appears to be done already.)

--
Matthias Andree
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


nate.diller at gmail

Jul 31, 2006, 3:56 PM

Post #173 of 223 (9870 views)
Permalink
Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion [In reply to]

On 7/31/06, Jeff V. Merkey <jmerkey [at] wolfmountaingroup> wrote:
> Gregory Maxwell wrote:
>
> > On 7/31/06, Alan Cox <alan [at] lxorguk> wrote:
> >
> >> Its well accepted that reiserfs3 has some robustness problems in the
> >> face of physical media errors. The structure of the file system and the
> >> tree basis make it very hard to avoid such problems. XFS appears to have
> >> managed to achieve both robustness and better data structures.
> >>
> >> How reiser4 compares I've no idea.
> >
> >
> > Citation?
> >
> > I ask because your clam differs from the only detailed research that
> > I'm aware of on the subject[1]. In figure 2 of the iron filesystems
> > paper that Ext3 is show to ignore a great number of data-loss inducing
> > failure conditions that Reiser3 detects an panics under.
> >
> > Are you sure that you aren't commenting on cases where Reiser3 alerts
> > the user to a critical data condition (via a panic) which leads to a
> > trouble report while ext3 ignores the problem which suppresses the
> > trouble report from the user?
> >
> > *1) http://www.cs.wisc.edu/adsl/Publications/iron-sosp05.pdf
>
> Hi Gregory, Wikimedia Foundation and LKML?
>
> How's Wikimania going. :-)
>
> What he says is correct. I have seen some serious issues with reiserfs
> in terms of stability and
> data corruption. Resier is however FASTER, but the statement is has
> robustness issues is accurate.
> I was using reiserfs but we opted to make EXT3 the default for Solera
> appliances, even when using Suse 10
> due to issues I have seen with data corruption and hard hangs on RAID 0
> read/write sector errors. I have
> stopped using it for local drives and based everything on EXT3. Not to
> say it won't get there eventually, but
> file systems have to endure a lot of time in the field and deployment
> befor they are ready for prime time.
>
> The Wikimedia appliances use Wolf Mountain, and I've tested it for about
> 4 months with few problems, but
> I only use it for hosting the Cherokee Langauge Wikipedia. It's
> performance is several magnitudes better
> than either EXT3 or ReiserFS. Despite this, for vertical wiki servers,
> its ok to go out with, folks can specifiy
> whether they want appliances with EXT3, Reiser, or WMFS, but iit's a
> long way from being "cooked"
> completely, though it does scale to 1 exabyte FS images.

i've seen you mention the Wolf Mountain FS in other emails, but google
isn't telling me a lot about it. Do you have a whitepaper? are there
any published benchmark results? what sort of workloads do you
benchmark?

NATE
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


nate.diller at gmail

Jul 31, 2006, 4:43 PM

Post #174 of 223 (9869 views)
Permalink
Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion [In reply to]

On 7/31/06, Jeff V. Merkey <jmerkey [at] wolfmountaingroup> wrote:
> Nate Diller wrote:
>
> > On 7/31/06, Jeff V. Merkey <jmerkey [at] wolfmountaingroup> wrote:
> >
> >> Gregory Maxwell wrote:
> >>
> >> > On 7/31/06, Alan Cox <alan [at] lxorguk> wrote:
> >> >
> >> >> Its well accepted that reiserfs3 has some robustness problems in the
> >> >> face of physical media errors. The structure of the file system
> >> and the
> >> >> tree basis make it very hard to avoid such problems. XFS appears
> >> to have
> >> >> managed to achieve both robustness and better data structures.
> >> >>
> >> >> How reiser4 compares I've no idea.
> >> >
> >> >
> >> > Citation?
> >> >
> >> > I ask because your clam differs from the only detailed research that
> >> > I'm aware of on the subject[1]. In figure 2 of the iron filesystems
> >> > paper that Ext3 is show to ignore a great number of data-loss inducing
> >> > failure conditions that Reiser3 detects an panics under.
> >> >
> >> > Are you sure that you aren't commenting on cases where Reiser3 alerts
> >> > the user to a critical data condition (via a panic) which leads to a
> >> > trouble report while ext3 ignores the problem which suppresses the
> >> > trouble report from the user?
> >> >
> >> > *1) http://www.cs.wisc.edu/adsl/Publications/iron-sosp05.pdf
> >>
> >> Hi Gregory, Wikimedia Foundation and LKML?
> >>
> >> How's Wikimania going. :-)
> >>
> >> What he says is correct. I have seen some serious issues with reiserfs
> >> in terms of stability and
> >> data corruption. Resier is however FASTER, but the statement is has
> >> robustness issues is accurate.
> >> I was using reiserfs but we opted to make EXT3 the default for Solera
> >> appliances, even when using Suse 10
> >> due to issues I have seen with data corruption and hard hangs on RAID 0
> >> read/write sector errors. I have
> >> stopped using it for local drives and based everything on EXT3. Not to
> >> say it won't get there eventually, but
> >> file systems have to endure a lot of time in the field and deployment
> >> befor they are ready for prime time.
> >>
> >> The Wikimedia appliances use Wolf Mountain, and I've tested it for about
> >> 4 months with few problems, but
> >> I only use it for hosting the Cherokee Langauge Wikipedia. It's
> >> performance is several magnitudes better
> >> than either EXT3 or ReiserFS. Despite this, for vertical wiki servers,
> >> its ok to go out with, folks can specifiy
> >> whether they want appliances with EXT3, Reiser, or WMFS, but iit's a
> >> long way from being "cooked"
> >> completely, though it does scale to 1 exabyte FS images.
> >
> >
> > i've seen you mention the Wolf Mountain FS in other emails, but google
> > isn't telling me a lot about it. Do you have a whitepaper? are there
> > any published benchmark results? what sort of workloads do you
> > benchmark?
> >
> > NATE
> >
> Wikipedia is the app for now. I have not done any benchmarks on the FS
> side, just the capture side, and its been transferred to
> another entity. I have no idea what they are naming it to, but I expect
> you may hear about it soon. One of the incarnations
> of it is Solera's DSFS which can be reviewed here:
>
> www.soleranetworks.com

so this is a single stream, write only? ...

> I can sustain 850 MB/S throughput from user space with it -- about 5 x
> any other FS. On some hardware, I've broken
> the 1.25 GB/S (gigabyte/second) windows with it.

and you're saying it scales to much higher multi-spindle
single-machine throughput. cool.

i'd love to see a whitepaper, or failing that, have an off-list
discussion of your approach and the various kernel limitations you ran
up against in testing. i don't suppose they invited you to the Kernel
Summit to talk about it, heh.

NATE
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


jmerkey at wolfmountaingroup

Jul 31, 2006, 4:52 PM

Post #175 of 223 (9865 views)
Permalink
Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion [In reply to]

Nate Diller wrote:

> On 7/31/06, Jeff V. Merkey <jmerkey [at] wolfmountaingroup> wrote:
>
>> Gregory Maxwell wrote:
>>
>> > On 7/31/06, Alan Cox <alan [at] lxorguk> wrote:
>> >
>> >> Its well accepted that reiserfs3 has some robustness problems in the
>> >> face of physical media errors. The structure of the file system
>> and the
>> >> tree basis make it very hard to avoid such problems. XFS appears
>> to have
>> >> managed to achieve both robustness and better data structures.
>> >>
>> >> How reiser4 compares I've no idea.
>> >
>> >
>> > Citation?
>> >
>> > I ask because your clam differs from the only detailed research that
>> > I'm aware of on the subject[1]. In figure 2 of the iron filesystems
>> > paper that Ext3 is show to ignore a great number of data-loss inducing
>> > failure conditions that Reiser3 detects an panics under.
>> >
>> > Are you sure that you aren't commenting on cases where Reiser3 alerts
>> > the user to a critical data condition (via a panic) which leads to a
>> > trouble report while ext3 ignores the problem which suppresses the
>> > trouble report from the user?
>> >
>> > *1) http://www.cs.wisc.edu/adsl/Publications/iron-sosp05.pdf
>>
>> Hi Gregory, Wikimedia Foundation and LKML?
>>
>> How's Wikimania going. :-)
>>
>> What he says is correct. I have seen some serious issues with reiserfs
>> in terms of stability and
>> data corruption. Resier is however FASTER, but the statement is has
>> robustness issues is accurate.
>> I was using reiserfs but we opted to make EXT3 the default for Solera
>> appliances, even when using Suse 10
>> due to issues I have seen with data corruption and hard hangs on RAID 0
>> read/write sector errors. I have
>> stopped using it for local drives and based everything on EXT3. Not to
>> say it won't get there eventually, but
>> file systems have to endure a lot of time in the field and deployment
>> befor they are ready for prime time.
>>
>> The Wikimedia appliances use Wolf Mountain, and I've tested it for about
>> 4 months with few problems, but
>> I only use it for hosting the Cherokee Langauge Wikipedia. It's
>> performance is several magnitudes better
>> than either EXT3 or ReiserFS. Despite this, for vertical wiki servers,
>> its ok to go out with, folks can specifiy
>> whether they want appliances with EXT3, Reiser, or WMFS, but iit's a
>> long way from being "cooked"
>> completely, though it does scale to 1 exabyte FS images.
>
>
> i've seen you mention the Wolf Mountain FS in other emails, but google
> isn't telling me a lot about it. Do you have a whitepaper? are there
> any published benchmark results? what sort of workloads do you
> benchmark?
>
> NATE
>
Wikipedia is the app for now. I have not done any benchmarks on the FS
side, just the capture side, and its been transferred to
another entity. I have no idea what they are naming it to, but I expect
you may hear about it soon. One of the incarnations
of it is Solera's DSFS which can be reviewed here:

www.soleranetworks.com

I can sustain 850 MB/S throughput from user space with it -- about 5 x
any other FS. On some hardware, I've broken
the 1.25 GB/S (gigabyte/second) windows with it.

Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

First page Previous page 1 2 3 4 5 6 7 8 9 Next page Last page  View All Linux kernel RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.