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

[Bodo Eggert <7eggert@elstempel.de>]

Jan-Benedict Glaw <jbglaw@lug-owl.de> wrote:
> On Mon, 2006-07-31 12:17:12 -0700, Clay Barnes <clay.barnes@gmail.com> wrote:
>> On 20:43 Mon 31 Jul     , Jan-Benedict Glaw wrote:
>> > On Mon, 2006-07-31 20:11:20 +0200, Matthias Andree <matthias.andree@gmx.de>
>> > > 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

<snip>

> 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.

- Once I had dying hdd without realizing this (I asumed heat problems or a
  failing power supply), and that caused the fs to become unaccessible.
  --rebuild-tree did the trick.

- I had a LVM on a set of some crappy disks with a reiser3fs-formated LV.  
  Windows decided it had to format the LVM partitions, and the reiserfs
  survived almost undamaged.

- I sometimes had errors on reiserfs resulting in inaccessible
  directories. I could fix that by moving them out of the way. (Maybe I
  could also have used --clean-attributes, I don't remember trying. OTOH,
  maybe that option is too new (2003).)

- I have an ext3 that can't be fixed by e2fsck (see below). fsck will fix
  some errors, trash some files and leave a fs waiting to throw the same
  error again. I'm fixing it using mkreiserfs now.

---------------------------------


Aug  2 15:15:23 server kernel: EXT3-fs error (device md(9,3)): ext3_free_blocks:
bit already cleared for block 13084101
Aug  2 15:15:23 server kernel: Aborting journal on device md(9,3).
Aug  2 15:15:23 server kernel: Remounting filesystem read-only
Aug  2 15:15:23 server kernel: ext3_reserve_inode_write: aborting transaction:
Journal has aborted in __ext3_journal_get_write_access<2>EXT3-fs error (device
md(9,3)) in ext3_reserve_inode_write: Journal has aborted
Aug  2 15:15:23 server kernel: EXT3-fs error (device md(9,3)) in ext3_truncate:
Journal has aborted
Aug  2 15:15:23 server kernel: ext3_reserve_inode_write: aborting transaction:
Journal has aborted in __ext3_journal_get_write_access<2>EXT3-fs error (device
md(9,3)) in ext3_reserve_inode_write: Journal has aborted
Aug  2 15:15:23 server kernel: EXT3-fs error (device md(9,3)) in
ext3_orphan_del: Journal has aborted
Aug  2 15:15:23 server kernel: ext3_reserve_inode_write: aborting transaction:
Journal has aborted in __ext3_journal_get_write_access<2>EXT3-fs error (device
md(9,3)) in ext3_reserve_inode_write: Journal has aborted
Aug  2 15:15:23 server kernel: EXT3-fs error (device md(9,3)) in
ext3_delete_inode: Journal has aborted



-- 
Ich danke GMX dafür, die Verwendung meiner Adressen mittels per SPF
verbreiteten Lügen zu sabotieren.

http://david.woodhou.se/why-not-spf.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/