ReiserFS is not suitable for a root FS.

ReiserFS is not suitable for a root FS.

[Russell Coker]

With a ReiserFS file system you can't FSCK a file system that is mounted 
read-only.  This means that when a root file system needs to be FSCK'd you 
need to boot from installation media (or convert the swap space into a 
temporary root file system).

It seems that the kernel drivers in 2.4.20 have some bugs whereby a corrupted 
file system can cause an immediate reboot, a system lock (caps-lock doesn't 
change the keyboard led), or a kernel Oops.  Ext2/3 does not appear to have 
such problems.

When machines crash it seems that there is a risk of a file system corruption, 
a crash on boot seems reasonably likely to damage the root file system.  My 
laptop (my main test machine) has had two serious corruptions of the root 
file system this year which caused kernel crashing on boot.

My conclusion is that until these issues are addressed ReiserFS is not 
suitable for a root file system.  Then when such problems occur it will be 
easy to fsck the file system.  Also ext2 has smaller kernel modules giving a 
smaller initrd.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

Re: ReiserFS is not suitable for a root FS.

[Oleg Drokin]

Hello!

On Sat, May 17, 2003 at 08:30:58PM +1000, Russell Coker wrote:

> When machines crash it seems that there is a risk of a file system corruption, 
> a crash on boot seems reasonably likely to damage the root file system.  My 
> laptop (my main test machine) has had two serious corruptions of the root 
> file system this year which caused kernel crashing on boot.

Well, if you cannot mount root fs and kernel crashes during that process, you
must boot off some other media because your fsck is still located on this root
filesytem.
This is true for any filesystem.

Bye,
    Oleg

Re: ReiserFS is not suitable for a root FS.

[Russell Coker]

On Sat, 17 May 2003 20:56, Oleg Drokin wrote:
> > When machines crash it seems that there is a risk of a file system
> > corruption, a crash on boot seems reasonably likely to damage the root
> > file system.  My laptop (my main test machine) has had two serious
> > corruptions of the root file system this year which caused kernel
> > crashing on boot.
>
> Well, if you cannot mount root fs and kernel crashes during that process,
> you must boot off some other media because your fsck is still located on
> this root filesytem.
> This is true for any filesystem.

The difference is that with other file systems the kernel code seems to be 
considerably less likely to crash.

The last time I had such a problem with Ext2 was in kernel 1.3.x days.

If the kernel tries to mount a file system and finds it to be extremely 
corrupt and the mount fails then naturally the result will be a panic if the 
file system in question is the root fs.

If the kernel can mount a file system but some directory entries, inodes, or 
other meta-data are corrupt then there is no excuse for crashing.  The files 
or directories should simply be inaccessable.  Ideally the kernel will log a 
message and either re-mount the file-system read-only or panic (in an orderly 
fashion) at the administrator's choice.

Having the kernel just trash system memory because of bad data on disk is a 
bug.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

Re: ReiserFS is not suitable for a root FS.

[Oleg Drokin]

Hello!

On Sat, May 17, 2003 at 09:09:53PM +1000, Russell Coker wrote:
> > Well, if you cannot mount root fs and kernel crashes during that process,
> > you must boot off some other media because your fsck is still located on
> > this root filesytem.
> > This is true for any filesystem.
> The difference is that with other file systems the kernel code seems to be 
> considerably less likely to crash.

Well, we try to handle all the cases in a good way.

> If the kernel can mount a file system but some directory entries, inodes, or 
> other meta-data are corrupt then there is no excuse for crashing.  The files 

We are accepting metadata snapshots in such cases and trying to make necessary fixes.
Where can we grab snapshots from your cases?

> or directories should simply be inaccessable.  Ideally the kernel will log a 
> message and either re-mount the file-system read-only or panic (in an orderly 
> fashion) at the administrator's choice.

Yes, that would be nice, of course. We started some work in this direction some time ago,
but we are not yet finished.

> Having the kernel just trash system memory because of bad data on disk is a 
> bug.

You cannot check all the on disk values, this is too bik performance impact.
Nobody does that in Linux, I think.

Bye,
    Oleg

Re: ReiserFS is not suitable for a root FS.

[Russell Coker]

On Sat, 17 May 2003 21:24, Oleg Drokin wrote:
> > Having the kernel just trash system memory because of bad data on disk is
> > a bug.
>
> You cannot check all the on disk values, this is too bik performance
> impact. Nobody does that in Linux, I think.

I really doubt that.

On 99.99% of all machines in use the data can be checked much faster than it 
can be read from disk.  There is little benefit in not checking, but there 
are huge problems when something goes wrong if you don't check.

Corrupted disks are not uncommon.  Otherwise we wouldn't need fsck programs!

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

Re: ReiserFS is not suitable for a root FS.

[Oleg Drokin]

Hello!

On Sat, May 17, 2003 at 09:32:34PM +1000, Russell Coker wrote:
> > > Having the kernel just trash system memory because of bad data on disk is
> > > a bug.
> > You cannot check all the on disk values, this is too bik performance
> > impact. Nobody does that in Linux, I think.
> I really doubt that.
> On 99.99% of all machines in use the data can be checked much faster than it 
> can be read from disk.  There is little benefit in not checking, but there 
> are huge problems when something goes wrong if you don't check.
> Corrupted disks are not uncommon.  Otherwise we wouldn't need fsck programs!

Turn on CONFIG_REISERFS_CHECK and notice how you became CPU-bound instead of disk bound
suddenly.
Nobody does this in general case in linux.

Bye,
    Oleg

Re: ReiserFS is not suitable for a root FS.

[Carl-Daniel Hailfinger]

Russell Coker wrote:
> With a ReiserFS file system you can't FSCK a file system that is mounted 
> read-only.  This means that when a root file system needs to be FSCK'd you 
> need to boot from installation media (or convert the swap space into a 
> temporary root file system).

I take this as a feature request. Right? It would certainly be nice to have.

> It seems that the kernel drivers in 2.4.20 have some bugs whereby a corrupted 
> file system can cause an immediate reboot, a system lock (caps-lock doesn't 
> change the keyboard led), or a kernel Oops.  Ext2/3 does not appear to have 
> such problems.

Could you please provide a metadata dump of the affected filesystem? The
behaviour you describe is not supposed to happen. Do you have a decoded
Oops for us to see what happened?

Believe me, ext2 had other problems like silent corruption even without
crashes or unclean shutdowns triggering it. After about 20-30 reboots,
my ext2 root filesystem was corrupted. This bug plagued me from
2.4.0-test until recently. It now seems to be fixed.

> When machines crash it seems that there is a risk of a file system corruption, 
> a crash on boot seems reasonably likely to damage the root file system.  My 
> laptop (my main test machine) has had two serious corruptions of the root 
> file system this year which caused kernel crashing on boot.
> 
> My conclusion is that until these issues are addressed ReiserFS is not 
> suitable for a root file system.  Then when such problems occur it will be 
> easy to fsck the file system.  Also ext2 has smaller kernel modules giving a 
                                      ^^^^
You surely mean ext3? Ext2 would not be a fair comparison because it has
no journaling. And if you're hunting for size, try jffs or jffs2.

> smaller initrd.


Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/

Re: ReiserFS is not suitable for a root FS.

[Russell Coker]

On Sat, 17 May 2003 21:14, Carl-Daniel Hailfinger wrote:
> Russell Coker wrote:
> > With a ReiserFS file system you can't FSCK a file system that is mounted
> > read-only.  This means that when a root file system needs to be FSCK'd
> > you need to boot from installation media (or convert the swap space into
> > a temporary root file system).
>
> I take this as a feature request. Right? It would certainly be nice to
> have.

Yes.

> > It seems that the kernel drivers in 2.4.20 have some bugs whereby a
> > corrupted file system can cause an immediate reboot, a system lock
> > (caps-lock doesn't change the keyboard led), or a kernel Oops.  Ext2/3
> > does not appear to have such problems.
>
> Could you please provide a metadata dump of the affected filesystem? The
> behaviour you describe is not supposed to happen. Do you have a decoded
> Oops for us to see what happened?

Unfortunately not.  It seems to happen to machines that have important 
production uses and which have little spare disk space.

> You surely mean ext3? Ext2 would not be a fair comparison because it has
> no journaling. And if you're hunting for size, try jffs or jffs2.

True, I meant ext3.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

Re: ReiserFS is not suitable for a root FS.

[Carl-Daniel Hailfinger]

Russell Coker wrote:
> On Sat, 17 May 2003 21:14, Carl-Daniel Hailfinger wrote:
> 
>>Russell Coker wrote:
>>
>>>With a ReiserFS file system you can't FSCK a file system that is mounted
>>>read-only.  This means that when a root file system needs to be FSCK'd
>>>you need to boot from installation media (or convert the swap space into
>>>a temporary root file system).
>>
>>I take this as a feature request. Right? It would certainly be nice to
>>have.
> 
> Yes.

Oleg? Given a statically linked reiserfsck binary completely loaded into
memory and an initrd below the reiserfs root filesystem, it should be
possible to completely unmount the root fs because the initrd is still
there and can serve as root fs.
In this situation, reiserfsck sould have no problems anymore because the
partition is not mounted at all.

>>>It seems that the kernel drivers in 2.4.20 have some bugs whereby a
>>>corrupted file system can cause an immediate reboot, a system lock
>>>(caps-lock doesn't change the keyboard led), or a kernel Oops.  Ext2/3
>>>does not appear to have such problems.
>>
>>Could you please provide a metadata dump of the affected filesystem? The
>>behaviour you describe is not supposed to happen. Do you have a decoded
>>Oops for us to see what happened?
> 
> 
> Unfortunately not.  It seems to happen to machines that have important 
> production uses and which have little spare disk space.

A compressed metadata dump uses about 0.1% of your disk space, i.e. ~2MB
for a 2GB partition. I'm sure you have at least 1% spare disk space.
Otherwise you are suffering from horrible performance anyway. There is
no filesystem I'm aware of which performs well with <5% free.
Corrections welcome.


Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/

Re: ReiserFS is not suitable for a root FS.

[Oleg Drokin]

Hello!

On Sat, May 17, 2003 at 02:01:00PM +0200, Carl-Daniel Hailfinger wrote:
> >>>With a ReiserFS file system you can't FSCK a file system that is mounted
> >>>read-only.  This means that when a root file system needs to be FSCK'd
> >>>you need to boot from installation media (or convert the swap space into
> >>>a temporary root file system).
> >>I take this as a feature request. Right? It would certainly be nice to
> >>have.
> > Yes.
> Oleg? Given a statically linked reiserfsck binary completely loaded into
> memory and an initrd below the reiserfs root filesystem, it should be
> possible to completely unmount the root fs because the initrd is still
> there and can serve as root fs.
> In this situation, reiserfsck sould have no problems anymore because the
> partition is not mounted at all.
> 

Initrd is not always present, you know. And sticking 300k (dynamic) or 600k (static)
reiserfsck in there is not all that fun probably.
Our current idea is to check if fsck is going to repair the
mounted partition and if this partition happens to contain the reiserfsck itself,
then mlockall() is done to page in all the pages of executable
(otherwise if we need to page something in in the middle of updating tree root pointer,
we won't be able to find anythig and die) and then proceed as normal.
This is still somewhat risky, though.
And if fsck will die in the middle of repairing rootfs (which still can happen) (And say it was
doing --rebuild-tree run), you won't be able to mount this fs anymore.

BTW, were there any news on "reiserfs corruptions on crypto loop mounted devices" tests with 2.4.21-rc2?

Thank you.

Bye,
    Oleg

Re: ReiserFS is not suitable for a root FS.

[Carl-Daniel Hailfinger]

Oleg Drokin wrote:

> BTW, were there any news on "reiserfs corruptions on crypto loop mounted devices" tests with 2.4.21-rc2?

Unfortunately, I wasn't successful in reproducing the corruption. OTOH,
I now use reiserfsprogs 3.6.7 instead of 3.6.4 before. Were there any
fixes committed to resize_reiserfs in the meantime?

What strikes me as odd is the fact that vs-5150 errors seem to coincide
with resizing when you look at past messages to the list.

Do your data structures grow linearly or to next 2^n bytes with
filesystem size? The last resize operations I tried did not cross any
2^n bytes boundary, while the ones before corruption crossed 512 MB,
1024 MB, 2048 MB boundary respectively.

Another shot in the dark: maybe resize_reiserfs does not update/check
the node level correctly, i.e. it checks against correct values before
resize instead of after resize?

Regards,
Carl-Daniel

Re: ReiserFS is not suitable for a root FS.

[Oleg Drokin]

Hello!

On Mon, May 19, 2003 at 12:22:25PM +0200, Carl-Daniel Hailfinger wrote:

> > BTW, were there any news on "reiserfs corruptions on crypto loop mounted devices" tests with 2.4.21-rc2?
> Unfortunately, I wasn't successful in reproducing the corruption. OTOH,
> I now use reiserfsprogs 3.6.7 instead of 3.6.4 before. Were there any
> fixes committed to resize_reiserfs in the meantime?

I do not see anything important, just some minor journal opening stuff.

> What strikes me as odd is the fact that vs-5150 errors seem to coincide
> with resizing when you look at past messages to the list.

Yes, this is strange.

> Do your data structures grow linearly or to next 2^n bytes with
> filesystem size? The last resize operations I tried did not cross any
> 2^n bytes boundary, while the ones before corruption crossed 512 MB,
> 1024 MB, 2048 MB boundary respectively.

No, the resize process only adds one more bitmap for every ~128M of disk space

> Another shot in the dark: maybe resize_reiserfs does not update/check
> the node level correctly, i.e. it checks against correct values before
> resize instead of after resize?

When you grow the filesystem, no tree nodes are touched at all.
Only size in superblock is updated and new bitmaps are added.

Bye,
    Oleg

Re: ReiserFS is not suitable for a root FS.

[Newsmail]

I did not saw any deadlocks or corruptions since 2.4.21-rc1, on 2.4.20 in 
the old times I was not able to reproduce any problems with crypto 
loop/reiserfs in testing environments, but they happened on production long 
up/highly fragmented systems. hopefully they are gone with 2.4.21-rc1
regards,
greg

>BTW, were there any news on "reiserfs corruptions on crypto loop mounted 
>devices" tests with 2.4.21-rc2?
>
>Thank you.
>
>Bye,
>     Oleg

Re: ReiserFS is not suitable for a root FS.

[Carl-Daniel Hailfinger]

Oleg Drokin wrote:
> Hello!
> 
> On Sat, May 17, 2003 at 02:01:00PM +0200, Carl-Daniel Hailfinger wrote:
> 
>>>>>With a ReiserFS file system you can't FSCK a file system that is mounted
>>>>>read-only.  This means that when a root file system needs to be FSCK'd
>>>>>you need to boot from installation media (or convert the swap space into
>>>>>a temporary root file system).
>>>>
>>>>I take this as a feature request. Right? It would certainly be nice to
>>>>have.
>>>
>>>Yes.
>>
>>Oleg? Given a statically linked reiserfsck binary completely loaded into
>>memory and an initrd below the reiserfs root filesystem, it should be
>>possible to completely unmount the root fs because the initrd is still
>>there and can serve as root fs.
>>In this situation, reiserfsck sould have no problems anymore because the
>>partition is not mounted at all.
>>
> 
> 
> Initrd is not always present, you know. And sticking 300k (dynamic) or 600k (static)
> reiserfsck in there is not all that fun probably.
> Our current idea is to check if fsck is going to repair the
> mounted partition and if this partition happens to contain the reiserfsck itself,
> then mlockall() is done to page in all the pages of executable
> (otherwise if we need to page something in in the middle of updating tree root pointer,
> we won't be able to find anythig and die) and then proceed as normal.

Any progress on this?

> This is still somewhat risky, though.
> And if fsck will die in the middle of repairing rootfs (which still can happen) (And say it was
> doing --rebuild-tree run), you won't be able to mount this fs anymore.


Regards,
Carl-Daniel

Re: ReiserFS is not suitable for a root FS.

[Vitaly Fertman]

[-- Attachment #1: Type: text/plain, Size: 1844 bytes --]


Hi, 

On Thursday 18 September 2003 15:50, Carl-Daniel Hailfinger wrote:
> Oleg Drokin wrote:
> > Hello!
> >
> > On Sat, May 17, 2003 at 02:01:00PM +0200, Carl-Daniel Hailfinger wrote:
> >>>>>With a ReiserFS file system you can't FSCK a file system that is
> >>>>> mounted read-only.  This means that when a root file system needs to
> >>>>> be FSCK'd you need to boot from installation media (or convert the
> >>>>> swap space into a temporary root file system).
> >>>>
> >>>>I take this as a feature request. Right? It would certainly be nice to
> >>>>have.
> >>>
> >>>Yes.
> >>
> >>Oleg? Given a statically linked reiserfsck binary completely loaded into
> >>memory and an initrd below the reiserfs root filesystem, it should be
> >>possible to completely unmount the root fs because the initrd is still
> >>there and can serve as root fs.
> >>In this situation, reiserfsck sould have no problems anymore because the
> >>partition is not mounted at all.
> >
> > Initrd is not always present, you know. And sticking 300k (dynamic) or
> > 600k (static) reiserfsck in there is not all that fun probably.
> > Our current idea is to check if fsck is going to repair the
> > mounted partition and if this partition happens to contain the reiserfsck
> > itself, then mlockall() is done to page in all the pages of executable
> > (otherwise if we need to page something in in the middle of updating tree
> > root pointer, we won't be able to find anythig and die) and then proceed
> > as normal.
>
> Any progress on this?
>
> > This is still somewhat risky, though.
> > And if fsck will die in the middle of repairing rootfs (which still can
> > happen) (And say it was doing --rebuild-tree run), you won't be able to
> > mount this fs anymore.

This patch seems to solve the problem, although it is not well tested yet.

-- 
Thanks,
Vitaly Fertman

[-- Attachment #2: mounted_fs_check.patch --]
[-- Type: text/x-diff, Size: 3170 bytes --]

===== fsck/main.c 1.68 vs edited =====
--- 1.68/reiserfsprogs/fsck/main.c	Wed Jul 30 12:05:41 2003
+++ edited/fsck/main.c	Thu Sep 18 18:01:18 2003
@@ -9,6 +9,7 @@
 
 #include "../include/config.h"
 #include "../version.h"
+#include <sys/mman.h>
 
 extern int screen_width;
 extern int screen_savebuffer_len;
@@ -742,6 +743,11 @@
 
     mark_filesystem_consistent (fs);
     clear_buffer_do_not_flush (fs->fs_super_bh);
+    
+    if (is_mounted_read_only(fs->fs_file_name)) {
+	reiserfs_warning(stderr, "\nThe partition is mounted ro. It is better "
+			 "to umount and mount it again.\n\n");
+    }
 
     /* write all dirty blocks */
     fsck_progress ("Syncing..");
@@ -751,33 +757,17 @@
     fsck_progress ("finished\n");
 }
 
+extern void prepare_fs_for_check(reiserfs_filsys_t * fs);
 
-static void rebuild_tree (reiserfs_filsys_t * fs)
-{
+static void rebuild_tree (reiserfs_filsys_t * fs) {
     time_t t;
     int ret;
 
-    if (is_mounted (fs->fs_file_name)) {
-	fsck_progress ("rebuild_tree: Cannot rebuild tree of mounted filesystem\n");
-	exit(EXIT_USER);
-    }
-
     init_rollback_file (state_rollback_file(fs), &fs->fs_blocksize, 
 	fsck_data(fs)->log);
     
-    reiserfs_reopen (fs, O_RDWR);
-
-    if (!fsck_skip_journal (fs)) {
-       if (reiserfs_journal_params_check(fs)) {
-	    reiserfs_close(fs);
-	    exit(EXIT_FATAL);
-	}
-
-	/* rebuild starts with journal replaying */
-	if (!fsck_skip_journal (fs))
-	    reiserfsck_replay_journal (fs);
-    }
-
+    prepare_fs_for_check(fs);
+    
     ret = reiserfs_open_ondisk_bitmap (fs);
     if (ret < 0) {
         fsck_progress ("reiserfsck: Could not open bitmap\n");
@@ -821,7 +811,7 @@
     }
 
     close_rollback_file ();
-    
+       
     time (&t);
     fsck_progress ("###########\n"
 		   "reiserfsck finished at %s"
@@ -829,10 +819,8 @@
     exit (EXIT_OK);
 }
 
-
 /* check umounted or read-only mounted filesystems only */
-static void prepare_fs_for_check(reiserfs_filsys_t * fs) 
-{
+void prepare_fs_for_check(reiserfs_filsys_t * fs) {
     /* The method could be called from auto_check already. */
     if (fs->fs_flags == O_RDWR) 
 	return;
@@ -840,20 +828,23 @@
     reiserfs_reopen (fs, O_RDWR);
     
     if (is_mounted (fs->fs_file_name)) {
-	/* filesystem seems mounted. */
-        if (fsck_mode (fs) == FSCK_CLEAN_ATTRIBUTES) {
-	    fsck_progress ("Partition %s is mounted, cannot clean attributes "
-		"on mounted device\n", fs->fs_file_name);
-	    reiserfs_close (fs);
-	    exit(EXIT_USER);
-        }
-
 	if (!is_mounted_read_only (fs->fs_file_name)) {
 	    fsck_progress ("Partition %s is mounted with write permissions, "
 		"cannot check it\n", fs->fs_file_name);
 	    reiserfs_close (fs);
 	    exit(EXIT_USER);
 	}
+	
+	/* If not CHECK mode, lock the process in the memory. */
+	if (fsck_mode (fs) != FSCK_CHECK) {
+	    if (mlockall(MCL_CURRENT)) {
+		    reiserfs_warning (stderr, "Failed to lock the process to "
+				      "fsck the mounted ro partition. %s.\n", 
+				      strerror(errno));
+		    exit(EXIT_OPER);
+	    }
+	}
+	
 	if (!reiserfs_journal_opened (fs)) {
 	    /* just to make sure */
 	    reiserfs_panic ("Journal is not opened");

Re: ReiserFS is not suitable for a root FS.

[Russell Coker]

On Sat, 17 May 2003 22:01, Carl-Daniel Hailfinger wrote:
> Oleg? Given a statically linked reiserfsck binary completely loaded into
> memory and an initrd below the reiserfs root filesystem, it should be
> possible to completely unmount the root fs because the initrd is still
> there and can serve as root fs.

If you have the fsck program is already on the initrd then this problem is 
already solved.

If you don't have the fsck program on the initrd (as is the case for a typical 
Debian install - and probably most other distributions too) then by the time 
the root filesystem is mounted the initrd is moved away by pivot_root and 
moving it back would be complex and not a supported feature of the boot 
scripts.

With kernel 2.6 I believe that the initrd will become a regular tmpfs, in 
which case the proceedure could be:
1) Kernel loads initrd.
2) Initrd mounts root read-only and checks for errors or other indications 
that fsck is needed.
3)  If fsck is needed then the fsck program is copied from /root/sbin to 
/sbin, /root is umounted fsck'd and remounted.
4)  Continue as usual.

With the 2.4 kernels we would need to mount a tmpfs before step 3, but the 
Debian initrd scripts already do that for other reasons, so it wouldn't be 
such a big change.

This could be done.  To do it you want to first get SUSE to do it and then 
some other RPM based distro.  Once it's considered a "standard" thing to do 
for ReiserFS it will be easier to get into Debian.

Getting changes to Debian to make up for features that aren't in ReiserFS but 
are in Ext2/3 will probably be rather difficult at the moment...

However this does not deal with the situation where an initrd is not being 
used.  Some people just don't like using an initrd.  For that case you would 
have to copy all relevant files to a tmpfs and use pivot_root to make it the 
root file system.  After that the best thing to do would be to reboot as 
testing all the possible options to ensure that the system will consistantly 
boot in a regular fashion after such a fsck will be difficult (and a reboot 
is not so arduous anyway).

> A compressed metadata dump uses about 0.1% of your disk space, i.e. ~2MB
> for a 2GB partition. I'm sure you have at least 1% spare disk space.
> Otherwise you are suffering from horrible performance anyway. There is
> no filesystem I'm aware of which performs well with <5% free.

Is this with the -p option of debugreiserfs?

I'll do it next time.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

Re: ReiserFS is not suitable for a root FS.

[bscott]

  Observation: Unix and its clones (such as Linux) have, traditionally, done
poorly when the root filesystem is not safe and sane.  The stance appears to
be (have been) that, if the root is damaged, the system doesn't have enough
marbles left to reliably repair itself.  At that point, you must boot from
some other filesystem.

  That is, I think, a not entirely unreasonable stance to take.  The root
filesystem is critical to any Unix system.  System binaries, device nodes,
and essential configuration files all live there.  If any of those are
damaged, you can no longer trust the system to function properly.  Sure, it
*may* work, but you are gambling at that point.  You are hoping that nothing
you need is damaged.  You cannot guarantee it.

  Rather than trying to engineer a perfect filesystem (which, I think, may
be impossible), it would be better (and far more practical) to develop
recovery mechanisms.  For less critical systems, you can simply boot from a
rescue CD.  For systems where uptime is essential, you can look at things
like putting recovery mechanisms in the initrd, or keep a "standby root"  
available in a separate partition (or even a separate disk).

-- 
Ben Scott <bscott@ntisys.com>
| The opinions expressed in this message are those of the author and do  |
| not represent the views or policy of any other person or organization. |
| All information is provided without warranty of any kind.              |

Re: ReiserFS is not suitable for a root FS.

[Dieter Nützel]

Am Montag, 19. Mai 2003 21:55 schrieb bscott@ntisys.com:
>   Observation: Unix and its clones (such as Linux) have, traditionally,
> done poorly when the root filesystem is not safe and sane.  The stance
> appears to be (have been) that, if the root is damaged, the system doesn't
> have enough marbles left to reliably repair itself.  At that point, you
> must boot from some other filesystem.

Former and current FSs of the "other OS" not?
NTFS is so stupid that it couldn't wake up itself when 
WINNT/system32/AUTOCHK.EXE is missing (on the root partition or rescue CD) or 
when it can't find a sane mft (master file table == inode table) even when 
there are intact copies of it on the disk.

But current NTFS patches for Linux can handle this...

Greetings,
	Dieter

-- 
Dieter Nützel
Leiter F&E, WEAR-A-BRAIN GmbH, Wiener Str. 5, 28359 Bremen, Germany
Mobil: 0162 673 09 09