R4 won't mount.
Hello. I'm trying out R4, and I'm having no luck mounting the device with the R4 filesystem. I've managed to compile libaal from /FIXED/ (./configure;make;make install). reiser4progs-0.4.20 is compiled with: --disable-debug --disable-fnv1-hash --disable-rupasov-hash --disable-tea-hash --disable-deg-hash --disable-short-keys --disable-specia --with-libaal=/usr/local/lib then: make;make install My problem is, that after making a R4 filesystem on a partition, it won't mount. I've tried various options, but still doesn't work. I wonder if I am missing something? I'm running debian testing on an athlon64 Can someone suggest some options or strategies? Thank you, Chris w.
Re: v3 experimental data=ordered and logging speedups for 2.6.1
On Mon, 2004-01-19 at 17:53, Dieter Nützel wrote: > 05 and 06 needed some handwork 'cause the SuSE kernel inclues xattrs and posix > acl's but nothing special. > Good to hear. I wasn't expecting the suse merge to be difficult, luckily it doesn't have many patches in it yet. Jeff and I will look at getting them into the suse kernel once data=journal is done as well. > An EXPORT was missing in linux/fs/buffer.c to compile ReiserFS 3.x.x as modul > (inode.c, unresolved symbol): > Thanks, I'll add it into the patch when I get back from linux world. -chris
Re: 2.4.24 Oops in find (maybe reiserfs related)
On Tue, 20 Jan 2004, Matthias Andree wrote: > This happened during the nightly updatedb, which calls find. The hex > string is "resi", "locate resi" finds a file in a reiserfs file system, > /usr. > > reiserfsck 3.6.11 afterwards fixed some > vpf-10680: The file [103048 103049] has the wrong block count in the > StatData (2) - corrected to (1) I have put the vmlinux, bzImage, modules and .config available, if anyone cares to have a look, send me a mail off-list and I'll by happy to return the URL. Marcello has been mailed the URL. -- Matthias Andree Encrypt your mail: my GnuPG key ID is 0x052E7D95
Re: Snapshot against 2.6.1 released.
Nikita Danilov wrote: Paolo Correnti writes: > I have the same "Domenico's problem": > - downloaded Kernel 2.6.1 > - applied SNAPSHOT 2004.01.19 FIXED > > Trying to mount Reiser4 partition all I obtain is: > > Wrong Master Super Block Magic > fs/reiser4/init_siper.c line 166 My apology for everyone for missing this bit in the READ.ME: you have to re-create your file-systems with mkfs supplied with this snapshot. Is it really mandatory to re-create or will a "fsck.reiser4 --build-fs" be able to fix the filesystem to the new format ? (the data on my reiser4 partition is not important at all, but i'd like to avoid erase it if possible). By the way, a small complaint: it would be nice to update the version numbers the next time there are changes, as e.g. for libaal-0.4.15, a diffstat with libaal-0.4.15 from the previous snapshot gives something like: [...] src/bitops.c|2 src/block.c |2 src/debug.c |2 src/device.c| 12 - src/exception.c |2 src/file.c |2 src/gauge.c |2 src/hash.c |2 src/libaal.c|4 src/list.c |2 src/malloc.c|2 src/print.c |2 src/stream.c|2 src/string.c| 21 -- src/ui.c|2 And the diff for reiser4progs-0.4.20 looks huge... 8-o Vince
Re: Snapshot against 2.6.1 released.
On Tue, Jan 20, 2004 at 02:11:45AM -0800, Paolo Correnti wrote: > P.S. Of course, pay attention to have always a "backup > partition" to be able to copy all your Reiser4 data > before testing new snapshots. Right, and keep a copy of the data from *before* you copied the data on that non-reiser4 partition. If you have another empty filesystem around for scratch data, you can use reiser4 for that, but not for data you care about.
(Fwd) wait_buffer_until_released on Debian 3 i386 2.4.22
Hi, the problem with the server crash has been repeated. It' s a completely new machine, installed december, 21 2003. The exact error in the logs is Jan 20 18:54:50 lxworksystem kernel: vs-3050: wait_buffer_until_released: nobody releases buffer (dev 68:07, size 4096, blocknr 3145728, count 3, list 0, state 0x10019, page c1568940, (UPTODATE, CLEAN, UNLOCKED)). Still waiting (-171000) JDIRTY !JWAIT and a smbd process is using 99% CPU. No Samba connect ist possible, ssh works so I could read the errors from /var/log/messages. Please let me know what I can do to solve this error as it's occurring now every 2-3 days! As I wrote before the machine is a HP Compaq ProLiant ML 350 G3 with 512 MB of memory, a Compaq Smart Array 641 with 128 MB cache and 4 discs (Compaq, I don't know the manufacturer) each 36 GB 10k rpm that are forming a hardware RAID5 array so the OS sees only one big drive with around 100 GB, and yes, the biggest partition with 87 G has about 46 GBs of data. Thank you in advance! Wolfgang --- Forwarded message follows --- From: "Wolfgang Riedmann" <[EMAIL PROTECTED]> Organization: Riedmann To: [EMAIL PROTECTED] Date sent: Fri, 16 Jan 2004 13:53:27 +0100 Subject:wait_buffer_until_released on Debian 3 i386 2.4.22 Priority: normal [ Double-click this line for list subscription options ] Hi, I' m having a problem on a HP/Compaq ProLiant ML350 with a SmartArray 641 RAID controller. Sometimes (the first time ten days ago, the second time yesterday eventing) a smbd process seems to provocate a wait_buffer_until_released error. The smbd process is taking 100% of the CPU, no Windows client can do anything, but sshd works so I can connect. Unfortunately, I was not able to see the messages after the reboot. For the OS the drive is one big drive with about 100 G space Is there any patch or fix or something other I can do? Thank you very much! Wolfgang --- End of forwarded message --- -- -- Wolfgang Riedmann -- Individuelle EDV-Lösungen - Soluzioni informatiche personalizzate -- I-39012 Meran, V. Laurin-Str. 2d -- http://www.riedmann.it - [EMAIL PROTECTED]
2.4.24 Oops in find (maybe reiserfs related)
This happened during the nightly updatedb, which calls find. The hex string is "resi", "locate resi" finds a file in a reiserfs file system, /usr. reiserfsck 3.6.11 afterwards fixed some vpf-10680: The file [103048 103049] has the wrong block count in the StatData (2) - corrected to (1) But I doubt these are related. Are they? Unable to handle kernel paging request at virtual address 72657369 printing eip: 72657369 *pde = Oops: CPU:0 EIP:0010:[<72657369>]Not tainted EFLAGS: 00010206 eax: f8bce0a0 ebx: 72657369 ecx: c1c1f13c edx: f117dec0 esi: ec837f98 edi: 08060828 ebp: b258 esp: ec837f8c ds: 0018 es: 0018 ss: 0018 Process find (pid: 7765, stackpage=ec837000) Stack: c014ebf1 f117dec0 b530 f117dec0 f7edae80 1000 ebcc0be0 0001 0008 0001 1000 ec836000 b530 c01090eb 08060831 b530 080541cc b530 08060828 b258 00c4 002b 002b 00c4 Call Trace:[sys_lstat64+129/144] [system_call+51/56] Call Trace:[] [] Code: Bad EIP value. -- Matthias Andree Encrypt your mail: my GnuPG key ID is 0x052E7D95
Re: reiserfs corruption: --rebuild-tree bug report
You didn't mention that you used the wrong commands OK, OK, I'm on a solid diet of crow for the next two weeks! Still, the initial error that downed the box showed reiserfs complaining about an inode, and the Seagate disk diagnostics showed no hardware failure. I might not have been as good to my filesystem as I should have been while recovering, but the event that started this saga was the box failing to come up because of a corrupt reiserfs. We're running reiserfs on all our desktops here, and on many servers at clients, and have never experienced the same thing before. -- Jean Jordaan http://www.upfrontsystems.co.za
Re: reiserfs corruption: --rebuild-tree bug report
> > I'm sending you the output of my 'reiserfck --rebuild-tree'. > It saved my ass, so I'm not complaining! However, I have no > idea how the filesystem got into this state. If you want me You didn't mention that you used the wrong commands to test which drive had failed, then used improper commands to restart the drive again and that you had a quite long discussion with Neil Brown on the raid-list who suggested to run a fsck, since the the raid-reconstruction might cause data-corruption now. Well, I really would blame any reiserfs-code for this ;-) Cheers, Bernd
reiserfs corruption: --rebuild-tree bug report
Hi all Prompted by this sentence in the manpage: If reiserfsck --check fails in some way you should also run reiserfsck --rebuild-tree, but we also encourage you to submit this as a bug report. I'm sending you the output of my 'reiserfck --rebuild-tree'. It saved my ass, so I'm not complaining! However, I have no idea how the filesystem got into this state. If you want me to check anything else about this drive, please let me know what to do. I'll have to reformat it soon though. /dev/md0 was part of a 3 disk RAID5 array, which one fine day booted with an inode error. The array was 3 IDE drives, mounted master, slave and master. cdimage root # mdadm --create /dev/md0 --raid-devices=3 --level=5 --spare-devices=0 --chunk=64 missing /dev/hdb3 /dev/hdc3 mdadm: /dev/hdb3 appears to be part of a raid array: level=5 devices=3 ctime=Tue Jan 20 10:35:45 2004 mdadm: /dev/hdc3 appears to be part of a raid array: level=5 devices=3 ctime=Tue Jan 20 10:09:43 2004 Continue creating array? y mdadm: array /dev/md0 started. cdimage root # mount -r -t reiserfs /dev/md0 /mnt/gentoo/raid/ mount: Not a directory cdimage root # cat /proc/mdstat Personalities : [raid5] read_ahead 1024 sectors md0 : active raid5 ide/host0/bus1/target0/lun0/part3[2] ide/host0/bus0/target1/lun0/part3[1] 76003328 blocks level 5, 64k chunk, algorithm 2 [3/2] [_UU] cdimage root # reiserfsck --check /dev/md0 <-reiserfsck, 2003-> reiserfsprogs 3.6.8 * ** If you are using the latest reiserfsprogs and it fails ** ** please email bug reports to [EMAIL PROTECTED], ** ** providing as much information as possible -- your ** ** hardware, kernel, patches, settings, all reiserfsck ** ** messages (including version), the reiserfsck logfile, ** ** check the syslog file for any related information. ** ** If you would like advice on using this program, support ** ** is available for $25 at www.namesys.com/support.html. ** * Will read-only check consistency of the filesystem on /dev/md0 Will put log info to 'stdout' Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes ### reiserfsck --check started at Tue Jan 20 12:19:38 2004 ### Replaying journal.. 0 transactions replayed Checking internal tree../ 1 (of 2)/ 1 (of 126)/ 1 (of 153)block 8211: The level of the node (25938) is not correct, (1) expected the problem in the internal node occured (8211), whole subtree is skipped finished Comparing bitmaps..vpf-10640: The on-disk and the correct bitmaps differs. Bad nodes were found, Semantic pass skipped 1 found corruptions can be fixed only during --rebuild-tree ### reiserfsck finished at Tue Jan 20 12:20:11 2004 ### cdimage root # mount -r -t reiserfs /dev/md0 /mnt/gentoo/raid/ mount: Not a directory cdimage root # reiserfsck --rebuild-tree /dev/md0 <-reiserfsck, 2003-> reiserfsprogs 3.6.8 * ** Do not run rebuild-tree unless something is broken and ** ** MAKE A BACKUP before using it. If you have bad sectors ** ** on a drive it is usually a bad idea to continue using ** ** it. Then you probably should get a working hard drive, ** ** copy the file system from the bad drive to the good one ** ** -- dd_rescue is a good tool for that -- and only then ** ** run this program. ** ** If you are using the latest reiserfsprogs and it fails ** ** please email bug reports to [EMAIL PROTECTED], ** ** providing as much information as possible -- your ** ** hardware, kernel, patches, settings, all reiserfsck ** ** messages (including version), the reiserfsck logfile, ** ** check the syslog file for any related information. ** ** If you would like advice on using this program, support ** ** is available for $25 at www.namesys.com/support.html. ** * Will rebuild the filesystem (/dev/md0) tree Will put log info to 'stdout' Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes Replaying journal.. 0 transactions replayed ### reiserfsck --rebuild-tree started at Tue Jan 20 12:44:02 2004 ### Pass 0: ### Pass 0 ### Loading on-disk bitmap .. ok, 647544 blocks marked used Skipping 8790 blocks (super block, journal, bitmaps) 638754 blocks will be read 0%20%40%60%80%100% left 0, 22026 /sec 193779 directory entries were hashed with "r5" hash. "r5" hash is selected Flushing..finished Read blocks (but not data blocks) 638754 Leaves among those 38854 Objectids found 8553 Pass 1 (will try to insert 38854 leaves): ### Pass 1 ### Looking for allocab
Re: Snapshot against 2.6.1 released.
alot. newest version: http://jpcox.student.iastate.edu/linux/patches/2.6/2.6.1/2.6.1-love6 On Tue, 2004-01-20 at 01:08, Mike Fedyk wrote: > On Tue, Jan 20, 2004 at 12:47:20AM +0100, Redeeman wrote: > > the love kernel patch provides reiser4 > > What else does this unknown patch do? -- Regards, Redeeman () ascii ribbon campaign - against html e-mail /\- against microsoft attachments
Re: Snapshot against 2.6.1 released.
On Mon, 19 Jan 2004 16:08:48 -0800 Mike Fedyk <[EMAIL PROTECTED]> wrote: > On Tue, Jan 20, 2004 at 12:47:20AM +0100, Redeeman wrote: > > the love kernel patch provides reiser4 > > What else does this unknown patch do? Have a look here: http://forums.gentoo.org/viewtopic.php?t=125170
Re: Snapshot against 2.6.1 released.
I'm sorry, I've read later Nikita message (Re: linux-2.6.0 + reiser4 oops) telling that Reiser4 partition has to be rebuilded. Now I've back my Reiser4 partition with no more mount problem. All the best PC P.S. Of course, pay attention to have always a "backup partition" to be able to copy all your Reiser4 data before testing new snapshots. --- Paolo Correnti <[EMAIL PROTECTED]> wrote: > I have the same "Domenico's problem": > - downloaded Kernel 2.6.1 > - applied SNAPSHOT 2004.01.19 FIXED > > Trying to mount Reiser4 partition all I obtain is: > > Wrong Master Super Block Magic > fs/reiser4/init_siper.c line 166 > > Going back to Kernel 2.6.0 + SNAPSHOT 2003.12.23 > I've no problems mounting and dismounting my Reiser4 > partition (only kernel panic during shutdown if I > try to use another Reiser4 partition, I think is a > dismount problem) > > I've also no problem with Kernel 2.6.1 + SNAPSHOT > 2003.12.23 using only one Reiser4 partition (with > more > partitions see the note above). > > All the best > > PC > > > --- Nikita Danilov <[EMAIL PROTECTED]> wrote: > > Domenico Andreoli writes: > > > Nikita Danilov wrote: > > > > Nikita Danilov writes: > > > > > Hello, > > > > > > > > > > new snapshot against 2.6.1 kernel is at > > > > > > > > > > http://namesys.com/snapshots/2004.01.19/ > > > > > > > > > > look into READ.ME file for details. > > > > > > > > Please also apply last-minute-fix.diff from > > there: it fixes some bug > > > > that slipped into snapshot. > > > > > > > > last-minute-fix.diff should be applied from > > fs/reiser4: > > > > > > > > $ cd /somewhere/fs/reiser4 > > > > $ patch -p1 < > > /somewhereelse/last-minute-fix.diff > > > > > > > > > > > > > > ehm.. my existing reiser4 partition is not > > mountable now that i recompiled > > > 2.6.1 using latest snapshot. it did not contain > > anything so i formatted > > > it, but nothing new happened. > > > > > > # mkfs.reiser4 /dev/hdc6 > > > > Is this mkfs.reiser4 from the 2004.01.19 snapshot? > > > > > mkfs.reiser4 0.4.20 > > > Copyright (C) 2001, 2002, 2003 by Hans Reiser, > > licensing governed by > > > reiser4progs/COPYING. > > > > > > Block size 4096 will be used. > > > > > > Linux 2.6.1-reiser4 is detected. > > > > > > Uuid 81a2b014-f272-4f6e-adad-e323c0cb10eb will > be > > used. > > > > > > Reiser4 is going to be created on /dev/hdc6. > > > > > > (Yes/No): yes > > > Creating reiser4 on /dev/hdc6...done > > > # mount /dev/hdc6 /mnt/extra2 > > > mount: you must specify the filesystem type > > > # mount /dev/hdc6 /mnt/extra2 -t reiser4 > > > mount: wrong fs type, bad option, bad > superblock > > on /dev/hdc6, > > > or too many mounted file systems > > > # > > > > What is in the kernel logs (dmesg, > > /var/log/messages)? > > > > > > > > > > > > Nikita. > > > __ > Do you Yahoo!? > Yahoo! Hotjobs: Enter the "Signing Bonus" > Sweepstakes > http://hotjobs.sweepstakes.yahoo.com/signingbonus __ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus
Re: Snapshot against 2.6.1 released.
Paolo Correnti writes: > I have the same "Domenico's problem": > - downloaded Kernel 2.6.1 > - applied SNAPSHOT 2004.01.19 FIXED > > Trying to mount Reiser4 partition all I obtain is: > > Wrong Master Super Block Magic > fs/reiser4/init_siper.c line 166 My apology for everyone for missing this bit in the READ.ME: you have to re-create your file-systems with mkfs supplied with this snapshot. > > Going back to Kernel 2.6.0 + SNAPSHOT 2003.12.23 > I've no problems mounting and dismounting my Reiser4 > partition (only kernel panic during shutdown if I > try to use another Reiser4 partition, I think is a > dismount problem) > > I've also no problem with Kernel 2.6.1 + SNAPSHOT > 2003.12.23 using only one Reiser4 partition (with more > partitions see the note above). > > All the best > > PC > Nikita. >
Re: Snapshot against 2.6.1 released.
I have the same "Domenico's problem": - downloaded Kernel 2.6.1 - applied SNAPSHOT 2004.01.19 FIXED Trying to mount Reiser4 partition all I obtain is: Wrong Master Super Block Magic fs/reiser4/init_siper.c line 166 Going back to Kernel 2.6.0 + SNAPSHOT 2003.12.23 I've no problems mounting and dismounting my Reiser4 partition (only kernel panic during shutdown if I try to use another Reiser4 partition, I think is a dismount problem) I've also no problem with Kernel 2.6.1 + SNAPSHOT 2003.12.23 using only one Reiser4 partition (with more partitions see the note above). All the best PC --- Nikita Danilov <[EMAIL PROTECTED]> wrote: > Domenico Andreoli writes: > > Nikita Danilov wrote: > > > Nikita Danilov writes: > > > > Hello, > > > > > > > > new snapshot against 2.6.1 kernel is at > > > > > > > > http://namesys.com/snapshots/2004.01.19/ > > > > > > > > look into READ.ME file for details. > > > > > > Please also apply last-minute-fix.diff from > there: it fixes some bug > > > that slipped into snapshot. > > > > > > last-minute-fix.diff should be applied from > fs/reiser4: > > > > > > $ cd /somewhere/fs/reiser4 > > > $ patch -p1 < > /somewhereelse/last-minute-fix.diff > > > > > > > > > > ehm.. my existing reiser4 partition is not > mountable now that i recompiled > > 2.6.1 using latest snapshot. it did not contain > anything so i formatted > > it, but nothing new happened. > > > > # mkfs.reiser4 /dev/hdc6 > > Is this mkfs.reiser4 from the 2004.01.19 snapshot? > > > mkfs.reiser4 0.4.20 > > Copyright (C) 2001, 2002, 2003 by Hans Reiser, > licensing governed by > > reiser4progs/COPYING. > > > > Block size 4096 will be used. > > > > Linux 2.6.1-reiser4 is detected. > > > > Uuid 81a2b014-f272-4f6e-adad-e323c0cb10eb will be > used. > > > > Reiser4 is going to be created on /dev/hdc6. > > > > (Yes/No): yes > > Creating reiser4 on /dev/hdc6...done > > # mount /dev/hdc6 /mnt/extra2 > > mount: you must specify the filesystem type > > # mount /dev/hdc6 /mnt/extra2 -t reiser4 > > mount: wrong fs type, bad option, bad superblock > on /dev/hdc6, > > or too many mounted file systems > > # > > What is in the kernel logs (dmesg, > /var/log/messages)? > > > > > > > Nikita. __ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus
