Re: [reiserfs-list] kernel panic with PAP-8252
> I tried reiserfsck with --check option. however completed with no error. > so I did not run reiserfsck with --rebuild-tree option. > machine is operating after reboot. Another note: please make sure that you use latest reiserfs-tools (version 3.6.2). You really should not be using anything older than this version, especially the 3.x. versions. Make sure you verify that, since it seems your system hasn't been updated in a long time, so I'm nearly sure that you *are* using outdated reiserfstools. Cheers, Kuba Ober
Re: [reiserfs-list] kernel panic with PAP-8252
On wtorek 30 lipiec 2002 08:20 am, K.Morikawa wrote: > Hello. > Thank you for your reply. > > I understand that kernel-2.2.18 and reiserfs-3.5.29 is old. > Also reiserfs-3.5.35(latest) is fixed many bugs too. > However, it is unable to up the version immediately. > because cause of this problem is indistinct and > It's necessary the inspection of the middleware and application related. By definition, user-level, unprivileged application errors shouldn't crash the kernel. So you should really forget about your application stuff and update the kernel to the latest 2.2, as well as latest reiserfs for 2.2. Or else you're asking for trouble. Again: application stuff should not crash the kernel if the kernel is fine. So even if your apps were completely broken, the kernel should be running fine. If you're getting kernel crashes, it's the kernel at fault. *Do* update ASAP. *Really*. You know, updating the kernel is not such a big job after all. Cheers, Kuba Ober
Re: [reiserfs-list] Permission denied !? - will i ever update my system again ? [Slightly OT]
On czwartek 18 lipiec 2002 05:40 am, Philippe Gramoullé wrote: > On Thu, 18 Jul 2002 13:06:26 +0400 > > Vitaly Fertman <[EMAIL PROTECTED]> wrote: > | > Hm. So you have duplicate oid issue most probably, reiserfsck > | > --rebuild-tree will cure that. Be sure to update to latest > | > reiserfsprogs > | > | --fix-fixable will cure about that also. > > BTW, would there be a noticeable difference in term of time it takes > between --fix-fixable and --rebuild-tree ? Definitely so. --fix-fixable is much faster, rebuilding tree on 600gigs of storage can take from two hours up to a day, AFAIK, depending on your system speed. Cheers, Kuba Ober
Re: [reiserfs-list] Filesystem errors
On środa 17 lipiec 2002 08:16 am, Oleg Drokin wrote: > Hello! > > On Wed, Jul 17, 2002 at 08:11:44AM -0400, Kuba Ober wrote: > > Did I mention that spinrite was about 100kb in size and written in > > assembler? > > This is not an advantage by any means in my view. It only means it is > x86 specific, most probably requires dos/windows, and hard to debug. You're right, but the guy simply kept it in assembler since mid-80's. And as far as I know him, and I know his coding style a little bit from disassembling the early spinrite II, his code is mostly more legible than poorly written C++. And the program, believe it or not, does not require debugging as it is. I think that the current version works fine w/o any changes nor patches since about 3 years or so. He does one hell of a testing job, and he always bases on previous code that worked (most probably one of the reasons why it's still in assembler). He is kind of assembly-maniac, but he has some windows utilities which are in assembler and do very cool things. Cheers, Kuba Ober
Re: [reiserfs-list] Filesystem errors
> On Wed, Jul 17, 2002 at 05:36:44PM +0930, Brian Marr wrote: > > Thanks for your comments. My system is still going under my watchful eye. > > I tried to copy the data using tar to a spare diskl > > tar -cplf - -C /myhardrive . | tar -xpvf - > > but this did not go far. I wonder if I could boot into rescue and do a > > dd ? I have not used this before. > > use dd_rescue tool, conventional dd is not working very good with > broken hard disks. Better yet, buy sprinrite (www.grc.com). It's an absolutely great tool, and more than worth the money. Although it doesn't handle out-of-place (i.e. data moving) recovery on non-fat filesystems, it can diagnose your disk and try recovering in-place. It uses quite advanced data recovery methods. It goes about as far as you can go without taking the hard drive out and plugging it into specialized hardware. Did I mention that spinrite was about 100kb in size and written in assembler? Cheers, Kuba Ober
Re: [reiserfs-list] jbd layer + reiserfs
On środa 12 czerwiec 2002 05:51 pm, Dirk Mueller wrote: > Hi, > > just being curious: is reiserfs anywhen going to use the jbd layer that was > introduced with the ext3 kernel merge ? I don't think that reiserfs journalling semantics are simple enough to be replicated by a journalled block device... that's my guess, I'm just a user, not a developer. Alas... well, maybe I'm wrong. If instead of opening and closing transactions in reiserfs journal it would be calling jfs transaction boundaries, maybe it's the same. Does reiserfs do any more magic in its journalling than simpky journal metadata block-writing? If it would be able to use jbd layer, then I assume some of the journal code could be put away (ie: dumped), at least in linux kernel tree (is there reiserfs for other platforms at all?). Cheers, Kuba Ober
Re: [reiserfs-list] Mount and file system size issue
On środa 12 czerwiec 2002 02:38 pm, you wrote: > Hello! > > On Wed, Jun 12, 2002 at 11:33:31AM -0400, Kuba Ober wrote: > > > Sorry! What is "sysrq"? > > > > It's a key on your keyboard, I hope. > > I afraid that most probably his system does not have keyboard and > operated through serial console of some kind. > Of course I might be wrong, but it seems he haev some kind of > embedded board (why do they use ARM CPU otherwise?) Hmmm... I would have to look into the sources, but wouldn't the sysrq have some encoding even through serial console (it's console after all)... Cheers, Kuba
Re: [reiserfs-list] Mount and file system size issue
On poniedziałek 10 czerwiec 2002 01:47 pm, bo wrote: > Hi , > > > On Sat, Jun 08, 2002 at 12:42:21PM -0700, bo wrote: > > >>reiserfs: warning: CONFIG_REISERFS_CHECK is set On > > >>reiserfs: warning: -it is slow mode for debugging > > >>reiserfs: checking transaction log(device 21:01) > > > > Hm. Would it help if you turn of CONFIG_REISERFS_CHECK config item? > > I will try it later, I could not rebuild the system now. > Are there anyway to turn it off on the command line? > > > > ??? It took 2-3 seconds(1 out of 5), or 3-4 munites(1 out of 5) > > > or forever(3 out of 5) to complete. > > > > All of that on the same filesystem (with same contents)? > > I mean it fails(hang) most of time when I try to mount the reiserfs with > 120G size after "mkreiserfs". > As you notice in the system status below, the CPU is occupied by the system > by 99.6(8) %. > I do not know why? > > > > System status at this time: from another console( run "top") > > > - > > > 1:40am up 1:40, 2 users, load average: 8.62, 7.71, 4.81 > > > 37 processes: 30 sleeping, 6 running, 1 zombie, 0 stopped > > > CPU states: 0.3% user, 99.6% system, 0.0% nice, 0.0% idle > > > > Ok, all the time is spent in kernel. > > Can you capture several traces for us please? > > ( several sysrq-p and/or sysrq-t outputs when this happens). > > Sorry! What is "sysrq"? It's a key on your keyboard, I hope. # echo 1 > /proc/sys/kernel sysrq # cat /usr/src/linux/Documentation/sysrq.txt Cheers, Kuba Ober
Re: [reiserfs-list] A couple of questions
> >One extra question on this. I assume that if in Fix mode and errors are > >encountered that fsck.resiserfs will prompt to fix each error and that > >there is no way to have it answer 'Yes' automatically like the ext2 -y > >option. > > > >If not then I will probably have to take Jonathan Briggs suggestion of a > >third process to answer 'Yes' repeatedly. > > > >Steve > > Why in the world do you want to run fsck without running it manually, > and passing all information to the user? What I'm thinking of is this: 1. If a filesystem is really too borked for fsck to recover useful stuff, it should be left alone. Either fsck is able to help or not. No need to ask user, fsck has more data to determine whether the fs makes a scant of sense, or if it has been messed up too much. 2. If we run fsck, we want to recover as much data as possible. That's what lost+found directory is for -- stuff that is not exactly clean for use, but may nevertheless be useful, gets hooked there. Why on earth does a filesystem check & recovery program need to ask questions to the user, which most users w/o intimate filesystem knowledge won't be able to answer at all? Looking at this list, what people want is to get their data back, as much as possible. They never want to get less than that. Why bother asking? That's one thing. Another thing is making fsck work on broken media, since that is what many unsuspecting users actually do. It should simply disregard read errors and try using whatever data there is in ok-read blocks. I don't think that asking too many questions is worth it. He who runs fsck in "fix" mode wants his data back (whatever is left of it). Certain things, like recovering the deleted files, may be worth specifying as options, but typical recovery stuff should be w/o questions in my opinion. At least that's what I'd expect all fsck's to do. Cheers, Kuba
Re: [reiserfs-list] 33 bad sectors kills 20GB
On sobota 04 maj 2002 10:58 am, Dax Kelson wrote: > This is a 20GB filesystem, used dd_rescue to make an image of the drive: > > Summary for /dev/hda3 -> hda3.img: > dd_rescue: (info): > ipos: 19711944.0k > opos: 19711944.0k > xferd: 19711944.0k > errs: 33 > errxfer:16.5k > succxfer: 19711927.5k > avg.rate:11743kB/s > > I then ran reiserfsck on the image file: > > look_for_lost: 6 files seem to left not linked to lost+found > Objects without names 1377 > Empty lost dirs removed 10 > Dirs linked to /lost+found: 149 > Dirs without stat data found 5 > Files linked to /lost+found 1228 > Pass 4 - done left 298, 0 /sec > Deleted unreachable items 117 > Syncing..done > Done > > (That took 3+ hours on a PIII 900, 512MB ram box) > > I mounted the image, and pretty much everything is gone. > > Is it normal for 33 bad sectors (16.5k) of data (out of 19711944k) to > completely kill the fs? > > Would I have better luck if I used the -A option on dd_rescue? > > "-A Always write blocks, zeroed if err (def=no);" What you did without using -A is following: fs with errors: xpbbxxx after dd: xpxxx-- Now assume that p is a pointer in the fs data structures that pointed to the last block (the last x). Now it points nowhere. You have reorganized your filesystem without updating all the pointers there are in the metadata. Nothing is going to rescue that wreck, lest some by-hand hexediting. You *absolutely* need to use -A. Or at least that's how I understand things. You may also need to do reiserfsck with rebuild-tree, although try without it first. I hope you have the latest version of reiserfstools -- if not, you *have* to get the latest one. Cheers, Kuba
