[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: ext3-2.4-0.9.6

Tom Rini wrote:
> ...
> > I'd assumed that this was related to the endianness fix.  You're
> > sure you were running with that in place?  If you can capture
> > a buffer trace that'd be great.
> I'm sure I had the fix in.  I re-ran the original test I had a few times
> and it was good.  I'll try and capture the buffer trace if it happens
> again, but last time I'm guessing it happened on my root fs, so the log
> couldn't goto disk.

OK, thanks.

> > >  On a
> > > related note, what does ext3 do to the disk when this happens,  I
> > > think I need to point the yaboot author at it since it couldn't
> > > load a kernel (which was fun, let me tell you.. :))
> >
> > ext3 is designed to nicely crash the machine if it thinks something
> > may be wrong with the fs - it's very defensive of your data.
> >
> > If yaboot is open firmware's native ext2 capability then presumably
> > it refuses to read an ext3 partition which needs recovery.  ext3
> > is designed to not be compatible with ext2 when it's in the
> > needs-recovery state.
> It's the linux bootloader that OF runs.  Is there any 'safe' way to read
> data off of an unclean ext3 partition?  I'm thinking grub might run into
> this problem too..

Well, LILO works OK with an unclean ext3 FS because it goes straight to
the underlying blocks.  If both grub and OF parse the superblock compatibility
bits then they could fail in this manner.

I *think* that at present an unrecovered ext3 filesystem is "incomaptible"
with ext2.  If, however we were to make it "read-only compatible" then
ext2-aware loaders would still be able to read the fs and boot from it.
But this stuff makes my head hurt - let's see what Andreas and Stephen
have to say.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]