[lug] Moving /
stimits at idcomm.com
Fri Apr 26 23:49:12 MDT 2002
"Timothy C. Klein" wrote:
> * John Karns (jkarns at csd.net) wrote:
> > On Fri, 26 Apr 2002, Dhruva Reddy said:
> > > Yeah, I saw some funkiness with ReiserFS--I could have
> > > sworn that when I was mucking around with the root
> > > partition, files started disappearing from /usr.
> > > Didn't exactly inspire confidence.
> > >
> > I've been using reiserfs on several machines for about a year. While I
> > encountered a problem on two ocassions - each on a different machine, but
> > the same symptom - I have never noticed a problem with disappearing files.
> > The symptom I saw was some kind of corruption where trying to access a
> > file or directroy would return an error msg something along the lines of
> > "cannot stat file". In one case the extent of the problem was limited to
> > 1 or 2 files, the other involved several dirs after attempting to patch
> > and compile X running under a 2.4.17 kernel.
> > With rfs, I think it's a very good idea to use only current kernels - at
> > least within a tree - I use 2.2.20 on most of the machines. Will probably
> > move to 2.4 sometime not too far off, as things seem to have settled down
> > a bit lately.
> I also experienced a problem much like this once. Ran reiserfsck and
> told it to rebuild the tree, and it went away. The really annoying one
> was when my machine suddenly lost its ability to boot from reiser. I
> don't know what caused it. The kernel would panic if attempted to mount
> any reiser partions, (it would give an oops about trying to kill init.)
> It was happening on all 4 reiser partitions I had. I ended up having to
> reformat the root parition as ext3 to get to go away. Then the other
> partions would mount. It was very strange. What was really odd was
> that if I booted with init=/bin/bash, rather than the usual init stuff, I
> could mount the reiser partitions fine.
> So like I said, that might not have been reiser's fault. But ditching
> the reiser partion on / fixed it.
FYI, any meta-journalling system is still subject to failures if the
metadata is written to log and then something stops the actual write of
data. Usually those are timed pretty close together, but you can't be
guaranteed that drives will flush when ordered (lots of buggy drives
like that). The only way you will get a perfect journalling is if you
use full journalling, and almost nothing is full journalling out there.
I'm not positive, but I understand the ext3 has both meta and full
journalling modes, but the full journalling has some problems (and maybe
was abandoned? anyone know about ext3 full journalling mode status?).
D. Stimits, stimits at idcomm.com
More information about the LUG