Jan-Benedict Glaw <[email protected]> wrote:
> On Mon, 2006-07-31 12:17:12 -0700, Clay Barnes <[email protected]> wrote:
>> On 20:43 Mon 31 Jul , Jan-Benedict Glaw wrote:
>> > On Mon, 2006-07-31 20:11:20 +0200, Matthias Andree <[email protected]>
>> > > 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
(changing subject to catch Ted's attention)
Bodo Eggert schrieb am 2006-08-05:
> - 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.
If such a bug persists with the latest released e2fsck version - you're
not showing e2fsck logs - I'm rather sure Ted Ts'o would like to have a
look at your file system meta data in order to teach e2fsck how to fix
this.
I've seen sufficient releases of reiserfsck that couldn't fix certain
bugs, too, so trying with the latest version of the respective tools is
a must.
--
Matthias Andree
On Sun, 6 Aug 2006, Matthias Andree wrote:
> (changing subject to catch Ted's attention)
> Bodo Eggert schrieb am 2006-08-05:
> > - 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.
>
> If such a bug persists with the latest released e2fsck version - you're
> not showing e2fsck logs - I'm rather sure Ted Ts'o would like to have a
> look at your file system meta data in order to teach e2fsck how to fix
> this.
Unfortunately I had no time to generate a fsck log before doing mkfs, nor
did I catch the fsck log before. The best thing I could do at that moment
was appending an except from thr log hoping it can be usefull.
My main intention was posting a differently biased view on fs robustness.
> I've seen sufficient releases of reiserfsck that couldn't fix certain
> bugs, too, so trying with the latest version of the respective tools is
> a must.
It was the latest version I found.
--
A. Top posters
Q. What's the most annoying thing on Usenet?