As mentioned in earlier posts, I'm running kernel 2.6.13 that came
with slackware 10. Used it, like it, never changed it. It uses
ReiserFS that came along. Thought it would be a good thing to do.
Then, I got around to inspect rc.S. Noticed it calls fsck during the
boot fase. I thought it should be reiserfsck since, well, I use
ReiserFS.
Changed the line :
/sbin/fsck $FORCEFSCK -C -a /
to
/sbin/reiserfsck --check /
that wasn't a good idea. the system boots until that line. It then
prompts me for confirmation to check. Then, after entering Yes, it
blows up complaining that there's no superblock. Running the
Reiserfsck with superblock re-creation doesn't work....it has no
superblock. The reiserfsck is version 3.6.19. Needless to say, I had
to boot from a CD to correct the line in rc.S.....and the system
happily boots from the reiserfs partition, which oddly has a nice
superblock.
What's wrong? Does this mean, that reiser effectively doesn't work,
since reiserfsck doesn't work? How to set-up properly so it does use
the journalling system to its fullest?
Thnx
Max
Sorry all,
The problem is that I should have used /dev/hda1 instead of just / as
with fsck....
But my original problem of two posts earlier remains. It's a system
requirement that a "hard" power down has to be survived. Most of the
time it's okay, but sometimes a get a message saying that fsck
detected a problem, but nothing is done to repair and sometimes the
kernel simply "has a few stack dumps" during module init's (e.g. in
the USB sub system). Needless to say, it won't work well after that.
The system wasn't writing at the time of power outtage. It's still a
bit of a mystery. what could be the reason for the linux kernel to
blow up during boot? Corrupted drive is my guess.....which brings me
back to the reiser stuff.
Max
If I'm not mistaken, reiserfsck can only be done a read only partition??
ken
...
>What's wrong? Does this mean, that reiser effectively doesn't work,
>since reiserfsck doesn't work? How to set-up properly so it does use
>the journalling system to its fullest?
Reiserfs does a journal replay check on mount, you don't need to add a
further check in startup scripts.
Grant.
--
http://bugsplatter.mine.nu/
fsck calls the appropriate fsck.* program. See e.g.
$ ls -l /sbin/fsck*
-rwxr-xr-x 1 root bin 18328 2004-04-11 18:40 /sbin/fsck*
-rwxr-xr-x 1 root bin 11172 2004-05-27 14:26 /sbin/fsck.cramfs*
-rwxr-xr-x 1 root bin 36 2004-04-11 18:40 /sbin/fsck.ext2*
-rwxr-xr-x 1 root bin 36 2004-04-11 18:40 /sbin/fsck.ext3*
lrwxrwxrwx 1 root root 9 2005-07-20 20:49 /sbin/fsck.hpfs -> /bin/true*
lrwxrwxrwx 1 root root 8 2005-07-20 20:49 /sbin/fsck.jfs -> jfs_fsck*
-rwxr-xr-x 1 root bin 23140 2004-05-27 14:26 /sbin/fsck.minix*
lrwxrwxrwx 1 root root 9 2005-07-20 20:49 /sbin/fsck.msdos -> /bin/true*
lrwxrwxrwx 1 root root 10 2005-07-20 20:49 /sbin/fsck.reiserfs -> reiserfsck*
lrwxrwxrwx 1 root root 9 2005-07-20 20:49 /sbin/fsck.umsdos -> /bin/true*
(this is from a Slackware 10 box)
So there should never be a need to do this:
> Changed the line :
>
> /sbin/fsck $FORCEFSCK -C -a /
>
> to
>
> /sbin/reiserfsck --check /
because /sbin/fsck will call fsck.reiserfs for any reiserfs filesystem
it finds. (I would guess that fsck converts the / to a device name
before calling fsck.reiserfs, but that's a guess.)
--keith
--
kkeller...@wombat.san-francisco.ca.us
(try just my userid to email me)
AOLSFAQ=http://www.therockgarden.ca/aolsfaq.txt
see X- headers for PGP signature information
Ain't that the truth!!!!
> speed of reiser against the awfull slowness of ext2 and ext3, I use reiser
> only for mail dirs and on backup servers, never use reiser for system
> partitions, never use it for critical things like databases, but for
> general /home, /tmp etc its acceptable, (I do use it on my rsync servers
> though for storage disks (not OS) as it makes backing up a mail server go
> from an hour on ext2/3 to 20 odd minutes on reiser.
I regret the day I installed reiser..I have two 0 byte mysql databases.
I'd run the reiser fsck to fix, but I've heard horror stories about that
process.
The only good thing about the reiserfs is that I'm anal about backups and
backups of my backups.
ken
I've been running reiserfs for years without issue, observed reiserfs
recovers from unexpected power fails by running a journal replay on mount.
YMMV?
Grant.
--
http://bugsplatter.mine.nu/
I think this is a big YMMV. Its a race condition between the wall
socket, hardware buffering, and your disk. I recently added
"data=journal" to the reiserfs mount options in /etc/fstab as a
further precaution. Haven't had the "opportunity" to see whether it
helps.
Having had a couple questionable recoveries using reiser, they were
definitely better than what ext2 would have left. Most of the files
appearing in lost+found seemed to be duplicates of files that weren't
blown away...
It appears that none of the filesystems are perfect wrt power
failures. ext3 has a slight edge; but it has enough other issues
(slow, inefficient use of space, 5% root kludge, ...) that I'm
sticking with reiser for now. xfs and jfs both look interesting; but
their handling of sudden failures doesn't seem to be any better.
- Daniel
Maybe I'm just having a bad run. I've run reiser since slack 9.1 came out,
it was the default install, no problems - nothing. The last couple of
months, power failures of the human and nature kind, a repairman from the
rental company yanked the plug on the computer to do some work on the
wall plugs, power failures from storms etc.
ken
>Grant wrote:
...
>> I've been running reiserfs for years without issue, observed reiserfs
>> recovers from unexpected power fails by running a journal replay on mount.
>>
>> YMMV?
>
>I think this is a big YMMV. Its a race condition between the wall
>socket, hardware buffering, and your disk. I recently added
>"data=journal" to the reiserfs mount options in /etc/fstab as a
>further precaution. Haven't had the "opportunity" to see whether it
>helps.
Just pull the power plug a few times :) Scary thought?
>
>Having had a couple questionable recoveries using reiser, they were
>definitely better than what ext2 would have left. Most of the files
>appearing in lost+found seemed to be duplicates of files that weren't
>blown away...
I feel reiserfs is practically non-recoverable, compare to ext3 where
partition may be mounted as ext2 and that there are file recovery tools
available.
Also note:
http://lists.opensuse.org/opensuse-factory/2006-09/msg00542.html
Reiserfs appears to have no viable future. Pity, as it is such a good
performer.
Grant.
--
http://bugsplatter.mine.nu/
I switched to reiserfs after suffering ext3 lockups I think with redhat9
or early fedora before I switched to slackware, slack-9.0.
Only time I lost data with reiserfs was when I ignored the mkreiserfs hint
to reboot after partitioning ;) Lost 200GB, spent a week or so reading CDs
back onto a file server... Hasn't happened since, I take more care now when
playing with partitions.
I still limit data partitions to 40GB, and keep important file backups
across a couple of machines.
What original work I do is open source and mirrored on the 'net, although
I've been known to ask a friend to email back a copy of files accidentally
lost -- before I wrote a decent backup script :o) I think my own actions
are a greater risk to data files to the chance of some powerfail dataloss.
Then again, I'm not willing to pull the plug a few times to test this
notion ;)
Grant.
--
http://bugsplatter.mine.nu/
I switched to reiserfs after suffering ext3 lockups I think with redhat9
Limiting data partitions to 40GB isn't really feasible when you have a
multiterabyte fileserver. ;-)
We've had some issues on cardinal with filesystem corruption on reiserfs;
we've got a file that simply can't be deleted. We could *probably* get
away with a reiserfsck --fix-fixable and clear it up, but we *definitely*
can't afford the results of it not working. That's just one data point,
of course, and it's not even a negative necessarily - that could happen
with any filesystem. The kicker is this: I know several other people
who have run across this same problem - all of them are extremely good
sysadmins, and all have had varying success with fixing the corruption.
There seems to be an inherent flaw in reiserfs that's causing these
issues, but of course, none of us has any concrete evidence of that, so
we're not going to make accusations.
All that being said, I've been running JFS on *all* of my production
systems (as well as my development/test systems), and I've had zero
problems thus far. That could certainly change at a moment's notice,
but two years of experience is good to this point.
-RW
>On 2008-02-13, Grant <g_r_a...@dodo.com.au> wrote:
>>
>> I still limit data partitions to 40GB, and keep important file backups
>> across a couple of machines.
>
>Limiting data partitions to 40GB isn't really feasible when you have a
>multiterabyte fileserver. ;-)
Call me old-fashioned... Don't have that kind of storage :o)
Grant.
--
http://bugsplatter.mine.nu/
I think I'm gonna settle for a 2 partition set-up. the first contains
the Linux set-up in a read-only partition and the second holds the app
with it's data. I'm gonna stick with Reiser for now, until another
option comes along with a compelling argument to use it.
Thnx for the discussion, though
Max
Remember the days of C:\ through to H:\ to try to keep your large (then)
drive on a DOS/Win system within whatever limits were affecting it that
week!
Pete
You'd need to go up to AAAA:\ to accomodate multiple terabytes! :)
I used to say the same until last evening :-)
Some race condition in loop/isomount of an iso on
a reiserfs partition also loop mounted, got I/O stuck and
the CPU went amok and the fan was spreading monkeys all over
the walls thus I tried to play smart and b0rked it all:
I rmmod the loop and loop_serpent to be able to kill the
thunar which was I/O pumping and while the rmmod -f eventually
succeeded the zombie still wouldn't die, I tried a reboot but
still no way and then zillion log mess printed about access error on
the partition so I finally powered-off the poor soul.
After the reboot the reiserfs partition was wrecked, no table and
no journal, the reconstruct phases gave out only zeroes in the tables
and though I could see there actually was data in some places of the
partition I didn't feel much like trying and repair by hand 50/100G
of reiserfs/twofish bubbles.
Now I've lost a movie copy, a few audio files I was working on,
and a pack of unfinished DLs, and some precious data I also had
on a backup plate, hence no big deal.
I also have one reiserfs partion less and one new JFS :-)