On 12 feb, 22:00, TheMaxer wrote:
> Dear all,
>
> 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

On 2008-02-12, TheMaxer wrote:
> Dear all,
>
> 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

If I'm not mistaken, reiserfsck can only be done a read only partition??

ken

On Tue, 12 Feb 2008 13:00:32 -0800 (PST), TheMaxer wrote:

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

On 2008-02-12, TheMaxer wrote:
>
> 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.

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-usenet@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

On Tue, 12 Feb 2008, TheMaxer wrote:

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

It is well documented that after hard crashes, reiser (like xfs/jfs) can
end up leaving you with zero byte files, you have to weigh up the fantastic
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.



--
Cheers
Res

mysql> update auth set Framed-IP-Address='127.0.0.127' where user= 'troll';

On 2008-02-12, Res wrote:
>
> It is well documented that after hard crashes, reiser (like xfs/jfs) can
> end up leaving you with zero byte files, you have to weigh up the fantastic

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

On Tue, 12 Feb 2008 20:58:27 -0600, No_One wrote:

>On 2008-02-12, Res wrote:
>>
>> It is well documented that after hard crashes, reiser (like xfs/jfs) can
>> end up leaving you with zero byte files, you have to weigh up the fantastic
>
>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.

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/

Grant wrote:
> On Tue, 12 Feb 2008 20:58:27 -0600, No_One wrote:
>
>> On 2008-02-12, Res wrote:
>>> It is well documented that after hard crashes, reiser (like xfs/jfs) can
>>> end up leaving you with zero byte files, you have to weigh up the fantastic
>> 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.
>
> 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.

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

On 2008-02-13, 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?
>
> Grant.

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

On Tue, 12 Feb 2008 22:39:57 -0500, D Herring wrote:

>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-f.../msg00542.html

Reiserfs appears to have no viable future. Pity, as it is such a good
performer.

Grant.
--
http://bugsplatter.mine.nu/

On Tue, 12 Feb 2008 22:06:20 -0600, No_One wrote:

>On 2008-02-13, 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?
>>
>> Grant.
>
>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.

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 ) 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/

On Tue, 12 Feb 2008 22:06:20 -0600, No_One wrote:

>On 2008-02-13, 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?
>>
>> Grant.
>
>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.

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 ) 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/

On 2008-02-13, Grant 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. ;-)

--keith

--
kkeller-usenet@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

On 2008-02-12, Res wrote:
>
> It is well documented that after hard crashes, reiser (like xfs/jfs) can
> end up leaving you with zero byte files, you have to weigh up the fantastic
> 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.


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 Tue, 12 Feb 2008 20:59:33 -0800, Keith Keller wrote:

>On 2008-02-13, Grant 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 )

Grant.
--
http://bugsplatter.mine.nu/

On Tue, 12 Feb 2008, No_One wrote:

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

Never had it happen to me, but I know many that it has happended to, thats
enough of a 'heads up' for me.

> The only good thing about the reiserfs is that I'm anal about backups and
> backups of my backups.

yep maybe one day ext3 wll bhe improved to be as fast, or maybe Hans
will beat the murder charge and will come back and fix up where it goes
wrong


--
Cheers
Res

mysql> update auth set Framed-IP-Address='127.0.0.127' where user= 'troll';

On Wed, 13 Feb 2008, Robby Workman wrote:

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

Although the reports are the same occurs, I only know of 1 person first
hand who had zero byte un-correctable files on jfs, this was however due
to power failure resulting from their buildings parabolic microwave unit
copping a direct lightning strike, there was nothing left of the gas
arrestor either so it must have abeen a doozy

--
Cheers
Res

mysql> update auth set Framed-IP-Address='127.0.0.127' where user= 'troll';

So, to resume, the judges are still out ;-)

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

Grant wrote:

> On Tue, 12 Feb 2008 20:59:33 -0800, Keith Keller
> wrote:
>
>>On 2008-02-13, Grant 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 )
>
> Grant.

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

--
http://www.petezilla.co.uk