Re: reiser4 problems
Hello, On Tuesday 21 March 2006 21:07, Sergey Ivanov wrote: > Hi, > I am sorry to report problems I had this night at my e-mail server. > Grepped reiser4 messages from /var/log/messages are at > http://parkheights.dyndns.org/r4log.bz2 > I have 2 processor system (athlon) with raid5 software array with 5x62.1 > GB, giving me 248.4GB for use. I have created lvm2 volumes for imap > folders there, and also have /usr, /var, /home and other resides on the > same raid5, everything formatted reiser4. > Yesterday the server stops working, but answer pings. I've rebooted it > with magic SysRQ key combinations after forced unmounting and syncing > all partitions. But in the night the problems reappear on some of > virtual volumes. In the morning I did remount -o ro and fsck.reiser4, > all but one volume was O.K, but one required rebuild-fs. Excuse me, I > have not saved the first fsck.reiser4 output. After rebuilding fs and > then rebooting the system, I've got immediately problems, the filesystem > was not accessible, all attempts to get ls of it finished with i/o error > messagees. (I have errors in /etc/fstab, the reiser4 volumes has lines > ending with 1 1, not 1 2 as it should be. I'm not sure it attributed to > the these problems). > The second fsck.reiser4 once more founded some problems, it's the log: > --- > [EMAIL PROTECTED] ~]# fsck.reiser4 -y --build-fs /dev/evms/imap-seriv > *** > This is an EXPERIMENTAL version of fsck.reiser4. Read README first. > *** > > Fscking the /dev/evms/imap-seriv block device. > Will check the consistency of the Reiser4 SuperBlock. > Will build the Reiser4 FileSystem. > * fsck.reiser4 started at Tue Mar 21 08:34:40 2006 > Reiser4 fs was detected on /dev/evms/imap-seriv. > > CHECKING STORAGE TREE > FSCK: Node (740803): The left delimiting key [29:1(SD):0:2a:0] in the > parent node (740782), pos (0/4294967295) does not match the first key > [0:0(NAME):0:0: > 0] in the node. Fixed. > FSCK: The tree height 4 found in the format is wrong. Fixed to 5. > Read nodes 440830 > Nodes left in the tree 440830 > Leaves of them 435415, Twigs of them 5323 > Time interval: Tue Mar 21 08:34:41 2006 - Tue Mar 21 08:44:54 2006 > CHECKING EXTENT REGIONS. > Read twigs 5323 > Time interval: Tue Mar 21 08:44:54 2006 - Tue Mar 21 08:46:14 2006 > LOOKING FOR UNCONNECTED NODES > Read nodes 0 > Good nodes 0 > Leaves of them 0, Twigs of them 0 > Time interval: Tue Mar 21 08:46:14 2006 - Tue Mar 21 08:46:14 2006 > CHECKING EXTENT REGIONS. > Read twigs 0 > Time interval: Tue Mar 21 08:46:14 2006 - Tue Mar 21 08:46:14 2006 > INSERTING UNCONNECTED NODES > 1. Twigs: done > 2. Twigs by item: done > 3. Leaves: done > 4. Leaves by item: done > Twigs: read 0, inserted 0, by item 0, empty 0 > Leaves: read 0, inserted 0, by item 0 > Time interval: Tue Mar 21 08:46:14 2006 - Tue Mar 21 08:46:14 2006 > CHECKING SEMANTIC TREE > FSCK: Node (762207), item (5), [6f6e9:6e6577:6f6eb] (stat40): > wrong size (20), Fixed to (21). > FSCK: Node (762207), item (5), [6f6e9:6e6577:6f6eb] (stat40): > wrong bytes (2473), Fixed to (2605). > FSCK: Node (773635), item (5), [6f62a:6e6577:6f62c] (stat40): > wrong size (6), Fixed to (7). > FSCK: Node (773635), item (5), [6f62a:6e6577:6f62c] (stat40): > wrong bytes (628), Fixed to (760). > FSCK: Node (773635), item (6), [6f62a:746d70:6f62b] (stat40): > wrong size (4), Fixed to (3). > FSCK: Node (773635), item (6), [6f62a:746d70:6f62b] (stat40): > wrong bytes (312), Fixed to (206). > Found 395956 objects. > Time interval: Tue Mar 21 08:46:14 2006 - Tue Mar 21 09:28:41 2006 > CLEANUPING STORAGE TREE > ... > --- (once more, excuse me, I have copied it from xterm while it was > 'cleanuping storage tree', so it's not the full log). wrong bytes is not a big problem, reiser4 indeed counted them wrongly some time ago, although it seems to be fixed already. the only serious problem here is at the beginning of the 'CHECKING STORAGE TREE' pass -- there must not be a key [0:0(NAME):0:0:0]. > After second fsck, I have unmounted and mounted it read only to save > data on ext3 partition and to wait answers and suggestions before using > reiser4 once more. which reiser4progs version do you use? it is already difficult to say why this strange key appeared -- you have already run several build-fs runs -- although it may be related to remount (I remember we used to have some problems before) or to fsck --build-fs. unmount you fs please and run 'fsck --check' on the unmounted fs -- check that all is right there now. which kernel version do you use? -- Vitaly
Re: rebuild-tree does not complete: filesystem full
Hello On Tuesday 21 March 2006 01:44, alftheo potgieter wrote: > Hi > I'm using the latest reiserfsck (3.6.19),, > My filesystem got corrupted by an unexpected power loss. Initially, I > could mount the filesystem read-only with minor problems. As I had > nowhere to back it up, I ran reiserfsck --rebuild-tree, which could not > complete, as the filesystem was full. it is possible to get such a corruption that fsck will need to insert some extra metadata to successfully repair the fs. this process may run out of disk space. I have an improved version of reiserfsck, which detects these corruptions and avoid these metadata insertion. however your fs already has these metadata inserted and there is probably no space to proceed. I will send you that improved reiserfsck, if it runs out of disk space too, you need to enlarge you partition, enlarge fs, and run reiserfsck again. If you will need to enlarge the partition, before doing it, please zero the space that will be added into the partition to avoid mixing your reiserfs metadata with another reiserfs metadata. > Now it is flagged as unmountable "to prevent further corruption". Is > there any way to restore the filesytem to the previous mountable but > corrupted state (which would be infinitely more useful)? I imagine > either finding the root node again or somehow growing the filesystem (as > I have since found enough space to grow it) > > Any help would be useful. > > alf > > -- Vitaly
Re: fatal "not directory found" error at pass 3a of reiserfsck
On Tuesday 14 March 2006 22:35, Alain Knaff wrote: > Vitaly Fertman wrote: > > Hi Alain, > > > > the fixed reiserfsprogs version is attched, it contains > > some bugfixes, please run it and report about the result. > > > > Thank you. > > Actually, the problem happened with reiserfs-3.6.18-5 (as shipped by > SuSE 9.3. and 10.0.). > > Later, I downloaded 3.6.19 from namesys, and that one already > successfully restored the disk (but due to size and slowness of our > hardware this took several hours and terminated just now a quarter of an > hour ago). > > Now, we'll first do a backup (yeah, we learned that lesson!), and after > that I'll re-run your 3.6.20 and report back (will probably take until > next morning, though) if rebuilding the tree has been finished, you do not need to rebuild it again, you can merely double check the fs consistency with --check (default) option. -- Vitaly
Re: reiserfsck --rebuild-tree aborted
On Tuesday 14 March 2006 21:29, [EMAIL PROTECTED] wrote: > > (sorry for multiple posts) > > After a crash my reiserfs partition behaved strangely (space usage 100%, > root wasn't allowed to see some files or write into some directories, > and some error messages when accessing files). > fsck.reiserfs found errors which it said must be corrected with > --rebuild-tree. > fsck.reiserfs --rebuild-tree aborted with the message "low on disk space". > Why is this? And: which pass does fsck abort on? there were made several improvements in reiserfsprogs regarding running out of disk space, you can try it if you want. the code is not released yet, so probably you will prefere to enlarge your partition and fs to allow fsck to complete. > What should I do now? > > Lots of regards, Jacob. > > P.S.: > I don't really have a larger partition. > > P.P.S.: > The reiserfs-partition was used last with a 2.6.15-1 kernel, > and fsckreiserfs (see above) was run with a 2.6.14 kernel from Kanotix. > The reiserfsprogs version was 3.6.19-1. Output of debugreiserfs was the > following: -- Vitaly
Re: fatal "not directory found" error at pass 3a of reiserfsck
On Tuesday 14 March 2006 18:51, Alain Knaff wrote: > We have a corrupted reiserfs filesystem here which can't even be repaired > with > --rebuid-tree. > > The error messages happens at pass 3a: > > > Pass 3a (looking for lost dir/files): > ### Pass 3a (lost+found pass) # > Looking for lost directories: > lost+found.c 116 _look_for_lost > not directory found > Aborted > > > What can we do to retrieve our files? this seems to be fixed already. sending the fixed reiserfsprogs version in the next email. -- Vitaly
Re: crash / kernel 2.6.15.3 / reiserfs 3.6 (bugreport)
On Sunday 05 March 2006 00:32, zotyalpb wrote:
> Hi
>
> I have an amd64 box with debian/sarge.
> it has two reiserfs, one for the root (sda1 - 36G), and one for home (md0 -
> 500G / raid10).
>
> Since a week it randomly crashes. I got reiserfs panic in the syslog, and
> the md0 is not responding, but the sda is working fine.
> I have to reboot to make it working again.
would you run reiserfsck on md0 please?
it looks like an fs corruption.
> Mar 4 18:04:38 free kernel: REISERFS: panic (device Null superblock):
> vs-8025: set_entry_sizes: (mode==p, insert_size==56), invalid length of
> directory item
> Mar 4 18:04:38 free kernel: --- [cut here ] - [please bite
> here ] -
> Mar 4 18:04:38 free kernel: Kernel BUG at fs/reiserfs/prints.c:362
> Mar 4 18:04:38 free kernel: invalid operand: [1] SMP
> Mar 4 18:04:38 free kernel: CPU 0
> Mar 4 18:04:39 free kernel: Modules linked in: nfs nfsd exportfs lockd
> sunrpc iptable_filter ip_tables 8250 serial_core generic i2c_nforce2 dm_mod
> w83627hf hwmon_vid i2c_isa 3c59x sata_sil
> Mar 4 18:04:39 free kernel: Pid: 962, comm: convert Not tainted 2.6.15.3 #5
> Mar 4 18:04:39 free kernel: RIP: 0010:[reiserfs_panic+193/234]
> {reiserfs_panic+193}
> Mar 4 18:04:39 free kernel: RSP: 0018:810021147638 EFLAGS: 00010296
> Mar 4 18:04:39 free kernel: RAX: 0087 RBX: 80362ca7
> RCX: 803d5768
> Mar 4 18:04:39 free kernel: RDX: 803d5768 RSI: 0246
> RDI: 803d5760
> Mar 4 18:04:39 free kernel: RBP: 0108 R08: 803d5768
> R09:
> Mar 4 18:04:39 free kernel: R10: 0001 R11: 0246
> R12:
> Mar 4 18:04:39 free kernel: R13: 0240 R14: 0001
> R15: 81004aea2d40
> Mar 4 18:04:39 free kernel: FS: 2cac3170()
> GS:8048c800() knlGS:
> Mar 4 18:04:39 free kernel: CS: 0010 DS: ES: CR0:
> 80050033
> Mar 4 18:04:39 free kernel: CR2: 2ad51090 CR3: 1be9d000
> CR4: 06e0
> Mar 4 18:04:39 free kernel: Process convert (pid: 962, threadinfo
> 810021146000, task 81001a2487b0)
> Mar 4 18:04:39 free kernel: Stack: 00300020 810021147728
> 810021147658
> Mar 4 18:04:39 free kernel:81007e3e9800 801d47a6
> 0070 0038
> Mar 4 18:04:39 free kernel:00011020 00011008
> Mar 4 18:04:39 free kernel: Call Trace:{get_cnode+24}
> {leaf_copy_items_entirely+1011}
> Mar 4 18:04:39 free kernel:{get_cnode+24}
> {journal_mark_dirty+373}
> Mar 4 18:04:39 free kernel:
> {leaf_delete_items_entirely+565}
> {direntry_create_vi+480}
> Mar 4 18:04:39 free kernel:
> {create_virtual_node+817}
> {ip_check_balance+839}
> Mar 4 18:04:39 free kernel:{fix_nodes+547}
> {reiserfs_paste_into_item+301}
> Mar 4 18:04:39 free kernel:
> {reiserfs_add_entry+781}
> {reiserfs_new_inode+1274}
> Mar 4 18:04:39 free kernel:
> {__reiserfs_permission+373}
> {reiserfs_create+346}
> Mar 4 18:04:39 free kernel:{vfs_create+225}
> {open_namei+383}
> Mar 4 18:04:39 free kernel:{filp_open+26}
> {get_unused_fd+108}
> Mar 4 18:04:39 free kernel:{do_sys_open+59}
> {system_call+126}
> Mar 4 18:04:39 free kernel:
> Mar 4 18:04:39 free kernel:
> Mar 4 18:04:39 free kernel: Code: 0f 0b 68 70 32 36 80 c2 6a 01 48 c7 c7 e0
> f6 36 80 4d 85 e4
> Mar 4 18:04:39 free kernel: RIP {reiserfs_panic+193} RSP
>
> Mar 4 18:04:39 free kernel: Badness in do_exit at kernel/exit.c:796
> Mar 4 18:04:39 free kernel:
> Mar 4 18:04:39 free kernel: Call Trace:{do_exit+75}
> {die_nmi+0}
> Mar 4 18:04:39 free kernel:{do_invalid_op+145}
> {reiserfs_panic+193}
> Mar 4 18:04:39 free kernel:{printk+141}
> {error_exit+0}
> Mar 4 18:04:39 free kernel:{reiserfs_panic+193}
> {reiserfs_panic+193}
> Mar 4 18:04:39 free kernel:{get_cnode+24}
> {leaf_copy_items_entirely+1011}
> Mar 4 18:04:39 free kernel:{get_cnode+24}
> {journal_mark_dirty+373}
> Mar 4 18:04:39 free kernel:
> {leaf_delete_items_entirely+565}
> {direntry_create_vi+480}
> Mar 4 18:04:39 free kernel:
> {create_virtual_node+817}
> {ip_check_balance+839}
> Mar 4 18:04:39 free kernel:{fix_nodes+547}
> {reiserfs_paste_into_item+301}
> Mar 4 18:04:39 free kernel:
> {reiserfs_add_entry+781}
> {reiserfs_new_inode+1274}
> Mar 4 18:04:39 free kernel:
> {__reiserfs_permission+373}
> {reiserfs_create+346}
> Mar 4 18:04:39 free kernel:{vfs_create+225}
> {open_namei+383}
> Mar 4 18:04:39 free kernel:{filp_open+26}
> {get_unused_fd+108}
> Mar 4 18:04:39 free kernel:{do_sys_open+59}
> {system_call+126}
> Mar 4 18:04:39 free kernel:
> Mar 4 18:04:39 free kernel: ReiserFS: sda1: warning: clm-2100: nesting info
> a different FS
>
> ...
>
> Mar 4 22:32:38
Re: Problem: --rebuild-tree failed
On Sunday 05 March 2006 22:07, Harald Weigl wrote: > Hello! Hello > I ended up in quite a mess. What has happened was: > - The file system ran full while copying CF-Card with pictures I took and > started to give a lot of error messages, some of them telling me that > fixing can only be done using "--rebuild-tree". > - I freed 10GB of disk space and first ran a --check and then a > --fix-fixable on the (unmounted) partition. > - As that went fine, I started a --rebuild-tree, which aborted twice. do you see anything related in the syslog? > Please find the logs for the correction runs attached. > > reiserfsck -V says: > reiserfsck 3.6.19 (2003 www.namesys.com) > > I'm running a Debian Etch (up to date) with the Debian standard kernel > Linux sydney 2.6.8-2-686 #1 Thu May 19 17:53:30 JST 2005 i686 GNU/Linux > > The system itself is a 1 GHz P3 with 512MB RAM used as a server with an > average load about 0.2. Hard disks are in pairs (RAID0) through a 3Ware > Escalade 8508 SATA Controller. The failing partition is located on a pair new > 300GB SATA-Drives, the Controller does not report any problems. > > The partition is about 300GB in size and holds a lot of big files (~50MBytes). > > I hope you can make sense of what I send you. If I shall provide further > information, please reply. > > In the end I have two questions: > - Is there a way to regain access to the partition again to save as much of > the contents as possible (I'll be getting me another set of harddisks this > week)? > - I simply copied about 900M of pictures from a CF-card. Is there anything I > should have considered (or consider in the future)? would you run: debugreiserfs -p | bzip2 -c > bz2 and provide the result for downloading? I have an improved reiserfsprogs version, although it is not a reslease yet, so I prefere to check how it works on metadata first. -- Vitaly
Re: reiser4 grub patch
On Friday 03 February 2006 14:37, luc wrote: > Hi, > > i have a big trouble with the grub with reiser4 patch. Look here: > > ./install.sh: > > grub> root (hd0,0) > ═Filesystem type is ext2fs, partition type 0x83 > grub> setup (hd0) > ═Checking if "/boot/grub/stage1" exists... yes > ═Checking if "/boot/grub/stage2" exists... yes > ═Checking if "/boot/grub/e2fs_stage1_5" exists... yes > ═Running "embed /boot/grub/e2fs_stage1_5 (hd0)"... ═15 sectors are > embedded. > succeeded > ═Running "install /boot/grub/stage1 (hd0) (hd0)1+15 p > (hd0,0)/boot/grub/stage /boot/grub/menu.lst"... failed > ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ should be > stage2 ═^^ > > > without reiser4 patch works perfectly is it grub 0.97? have you taken the patched grub from our ftp or patched it by yourself? have you installed the grub or testing it all in the source dir? do not forget that new fs images should be put into /boot/grub/, otherwise you are trying old images with new grub. reiser4 fs seems to be not involved into that installation process, am I correct that an fs grub source sits on, /, (hd0,0), other used fs are not reiser4 ones? which files do you have in (hd0,0)/boot/grub/? -- Vitaly
Re: multiple rebuild-tree aborts
On Monday 30 January 2006 18:57, Bryant, Phillip -AES wrote: > RedHat ES Workstation, 2.6.9-11smp > Dell Precision 530 workstation > Dell Powervault RAID with 500Gb RAID partition > reiserfs 3.6.19 > > The virtual RAID disk was inadvertantly broken when the Dell powervault was > split into two seperate controlers. When the server was brought back up the > original virtual disk had to be recreated on the RAID controler. > > I was surprised that the problem did not wipe out all of the data on the > partition but reiserfsck --rebuild-tree had been unable to repiar the > partition so it can be mounted. It holds the backups for all servers and > pc's in my office. > > This last run did not abort with bad root block as all previous runs had (4). would you describe the message appeared 4 times more precisely? > last run ended with: > > Pass 3a (looking for lost dir/files): > Looking for lost directories: > /1956276_1956286/304c28018c1a645410c2905a0c355871semantic_rebuild.c 563 > get_next_directory_item > get_next_directory_item: item [61312722 61312723 0x2a1 DRCT (2)]: hidden > entry 0 '' > Aborted > > I believe all previous aborts happened in phase 0 but I don't really know if > this is a good sign or not. would you extract the reiserfs metadata with debugreiserfs -p | bzip2 -c > .bz2 and provide the result file for downloading to allow us to debug the fsck locally? have fsck ended with the last message 1 or more times? > I've run debugreiserfs and gotten this: > > Filesystem state: consistency is not checked after last mounting > Reiserfs super block in block 16 on 0x5001 of format 3.6 with standard journal > Count of blocks on the device: 143372080 > Number of bitmaps: 4376 > Blocksize: 4096 > Free blocks (count of blocks - used [journal, bitmaps, data, reserved] > blocks): 143372080 > Root block: 0 > Filesystem is NOT clean > Tree height: 65535 > Hash function used to sort names: "r5" > Objectid map size 972, max 972 > Journal parameters: > Device [0x0] > Magic [0x5e4c8641] > Size 8193 blocks (including 1 for journal header) (first block 18) > Max transaction length 1024 blocks > Max batch size 900 blocks > Max commit age 30 > Blocks reserved by journal: 0 > Fs state field: 0xfa02: > FATAL corruptions exist. > sb_version: 2 > inode generation number: 23368281 > UUID: fbf09431-c46c-4075-bb79-748d7b26f0a0 > LABEL: > Set flags in SB: > ATTRIBUTES CLEAN > > > This e-mail and any files transmitted with it are proprietary and intended > solely for the use of the individual or entity to whom they are addressed. > If you have received this e-mail in error please notify the sender. Please > note that any views or opinions presented in this e-mail are solely those > of the author and do not necessarily represent those of ITT Industries, Inc. > The recipient should check this e-mail and any attachments for the presence > of viruses. ITT Industries accepts no liability for any damage caused by any > virus transmitted by this e-mail. > > -- Vitaly
Re: reiserfs tails and disk space
On Thursday 19 January 2006 22:53, Bruce Guenter wrote: > On Wed, Jan 18, 2006 at 09:34:49PM +0300, Vitaly Fertman wrote: > > thank you for the report, the attached patch should fix > > the broken mount options. please try it. > > It does indeed fix the problem. What other mount options would have > been affected by this problem? it does not seem to brake anything else. > In what version of the kernel was this > problem introduced? 2.6.13. -- Vitaly
Re: reiserfs tails and disk space
On Tuesday 17 January 2006 21:58, Hans Reiser wrote:
> The result is not expected, Vitaly please look into it.
>
> Hans
>
> Bruce Guenter wrote:
>
> >Hi.
> >
> >I've been running a few tests with reiserfs and tails, and have been
> >unable to create a setup where the use (or lack) of tails results in a
> >significant difference in the amount of disk space used.
thank you for the report, the attached patch should fix
the broken mount options. please try it.
> >Here's what I've done:
> >
> >1. Create a fresh 1GB filesystem (in a file on loopback), using reiserfs
> >with no options.
> >
> >2. Mount the filesystem with either no options, "notail", "tails=off",
> >"tails=on", or "tails=small".
> >
> >3. Unpack a sources tarball onto the filesystem, consisting of two fully
> >compiled versions of the linux kernel. The tarball contains 47996 files
> >and 3321 directories totalling about 660MB of space.
> >
> >4. Measure the free disk space using df.
> >
> >5. Use dd to fill up the free disk space and count how many 1kB blocks
> >it could write.
> >
> >In all of the tests, the result was within 12kB of each other. In fact,
> >the tests with "notail" or "tails=off" options had more usable disk
> >space than when using tails.
> >
> >Results:
> >
> >Options1K-blocksUsed Available
> >default 1023964 645988 377976
> >notail 1023964 645988 377976
> >tails=off1023964 645996 377968
> >tails=on 1023964 646000 377964
> >tails=small 1023964 645996 377968
> >
> >default 377600+0 records out
> >notail 377600+0 records out
> >tails=off377592+0 records out
> >tails=on 377588+0 records out
> >tails=small 377592+0 records out
> >
> >I've put the log files and scripts up for review at
> > http://untroubled.org/reiserfsdf/
> >I'm using Gentoo Linux, kernel 2.6.14-gentoo-r5
> >
> >Am I missing something, is this an expected result, or is something
> >broken?
> >
> >Thanks.
> >
> >
>
>
>
--
Vitaly
--- linux-2.6.15-rc5-mm3-clean/fs/reiserfs/super.c 2005-12-21 23:57:54.0 +0300
+++ linux-2.6.15-rc5-mm3/fs/reiserfs/super.c 2006-01-18 21:28:25.206460792 +0300
@@ -1131,7 +1131,7 @@
REISERFS_SB(s)->s_mount_opt &= ~(1 << REISERFS_ATTRS);
}
} else if (le32_to_cpu(rs->s_flags) & reiserfs_attrs_cleared) {
- REISERFS_SB(s)->s_mount_opt |= REISERFS_ATTRS;
+ REISERFS_SB(s)->s_mount_opt |= (1 << REISERFS_ATTRS);
}
}
Re: Reiser disc hosed?
On Saturday 07 January 2006 06:46, Eric P wrote: > So I'm doing an 'mplayer -dumpfile', and before I know it I've > completely filled the last 10GB of my hard drive (total 80GB). It > wasn't were the OS resided; just a HD used for a file holding space. > > Anyway, after reaching 100%, the folder I was working in became > non-working. When I would do 'ls' from its parent folder, it said > something like 'Couldn't lstat /folder permission denied'; even as root. > > (sorry if my details are sketchy. Unfortunately, I tried tackling > this problem while I had a fever. Bad idea.). > > > It's a reiser4 FS, so I umounted and ran: > # fsck.reiser4 /dev/hdb1 > ... > Warn : Fatal corruptions were found. Semantic pass is skipped. > * fsck.reiser4 finished at Thu Jan 5 18:35:18 2006 > Closing fs...done > > 1 fatal corruptions were detected in FileSystem. Run with --build-fs > option to fix them. have you run fsck.reiser4 --build-sb before running this to rebuild the super block? > So, as suggested, I ran: > # fsck.reiser4 --build-fs /dev/hdb1 (which ran for ~30 min) > ... > Warn : Reiser4 storage tree does not exist. Filter pass skipped. > ... > Fatal: No reiser4 metadata were found. Semantic pass is skipped. > * fsck.reiser4 finished at Thu Jan 5 19:16:50 2006 > Closing fs...done > > NO REISER4 METADATA WERE FOUND. FS RECOVERY IS NOT POSSIBLE. it looks like it is not reiser4 or probably the partition table got corrupted or the fs was wiped out somehow. If you need our assistance, visit www.namesys.com/support.html please. > So this is (ahem) bad, huh? Am I screwed? Or is there any way to > recover some of the files? > > Thanks for reading! > Eric P. > > -- Vitaly
Re: ReiserFS Recovery
On Monday 05 December 2005 01:27, Marcus Fleige wrote: > Hi list, > > i got a problem i need to get solved really badly. Maybe you can help? > It is extremly important to me to get that data back. > > For the situation: > > I got a linux server here with a data disk and a backup disk, both > encrypted using loop-aes (mount options loop=/dev/loopX, > encryption=aes-256) with the data disk based on reiserfs, the backup > disk with the most important data on ext3. Everything was fine up to > last sunday, when after a reboot _both_ disks rendered unmountable. > > A first diagnosis showed a defective partition table. Dumping the first > MBs of the Disk, it seemed like the beginning of my disk had been > overwritten, killing my partition table and my reiserfs headers with > superblocks etc. Before anything else, i made a total backup of the > encrypted disk to another machine. > > Mounting the drive died with the following: > > homer ~ # mount /exports > mount:wrong fs type, bad option, bad superblock on /dev/loop0 > missing codepage or other error > In some cases useful info is found in syslog - try > dmesg | tail or so > > dmesg says: > > VFS: Can't find reiserfs filesystem on dev loop0 > > After that, i tried to fsck the partition: > > homer ~ # losetup -e aes-256 /dev/loop0 /dev/hdb5 > Password: > homer ~ # reiserfsck /dev/loop0 > reiserfsck 3.6.19 (2003 www.namesys.com) > > Will read-only check consistency of the filesystem on /dev/loop0 > Will put log info to 'stdout' > > Do you want to run this program?[N/Yes] (note need to type Yes > if you do):Yes > > reiserfs_open: the reiserfs superblock cannot be found on > /dev/loop0. Failed to open the filesystem. > > If the partition table has not been changed, and the partition > is valid and it really contains a reiserfs partition, then > the superblock is corrupted and you need to run this utility > with --rebuild-sb. > > Do'h! > > homer ~ # reiserfsck --rebuild-sb /dev/loop0 > reiserfsck 3.6.19 (2003 www.namesys.com) > > Will check superblock and rebuild it if needed > Will put log info to 'stdout' > > Do you want to run this program?[N/Yes] (note need to type Yes > if you do):Yes > > reiserfs_open: the reiserfs superblock cannot be found on > /dev/loop0. > > what the version of ReiserFS do you use[1-4] > (1) 3.6.x > (2) >=3.5.9 (introduced in the middle of 1999) (if you > use linux 2.2, choose this one) > (3) < 3.5.9 converted to new format (don't choose if > unsure) > (4) < 3.5.9 (this is very old format, don't choose if > unsure) > (X) exit > 1 > > Enter block size [4096]: > > > No journal device was specified. (If journal is not available, > re-run with --no-journal-available option specified). > > Is journal default? (y/n)[y]: > > Did you use resizer(y/n)[n]: > > rebuild-sb: no uuid found, a new uuid was generated > (cd9f7433-6d06-4bc8-8816-22269692eb9c) > > rebuild-sb: You either have a corrupted journal or have just > changed the start of the partition with some partition table > editor. If you are sure that the start of the partition is ok, > rebuild the journal header. > Do you want to rebuild the journal header? (y/n)[n]: you need to rebuild the journal header to proceed. the answer defaults to 'n' to avoid that block overwriting by mistake. > homer ~ # mkreiserfs /dev/loop0 > homer ~ # reiserfsck --rebuild-tree --scan-whole-partition /dev/loop0 have you made a backup before mkfs? The whole partition is wiped out or you decript it wrongly or the partition table is still not correct. We may try to help with the 3rd case, although we cannot garantee the result. If you need our assistance please visit www.namesys.com/support.html. > Again, without any result. > > Lately, i joined #reiser4 on IRC, finding 'vs' (Vladimir Saveliev?) > willing to help (thanks again!). We ran the 'scan-reiserfs'-utility, > trying to find reiser leaf nodes on the loop device. The scan found 4 > nodes, but to make sure not to miss anything, i decided to restore the > backup to the original data disk. > > After restore, i ran decrypted the whole disk with > homer ~ # losetup -e aes-256 /dev/loop0 /dev/hdb > > and tried to find any reiserfs related info with scan-reiserfs again. > Result: > > homer ~ # ./scan-reiserfs /dev/loop0 1 151324236 > main: 485 > read failed > errno: Success > > Has anyone an idea how to recover the data on that disk? > > Thanks in advance, > > Marcus > > -- Vitaly
Re: Booting problem from root reiser4 after new kernel
On Saturday 03 December 2005 20:26, Charles Johnston wrote: > I've been keeping quite up-to-date with new kernels, so I compiled > 2.6.15-rc4 plus the reiser4 patches from 2.6.15-rc3-mm1 plus the > reiser4-fix-fsync.patch. > > I'm using grub 0.97 with the 20050808 reiser4 patch. > > Put the new kernel in /boot, modified /boot/grub/menu.lst for it, > rebooted, and got the following error, after "Uncompressing Linux": > > ran out of input data > > system halted > > > So, after trying different things to no avail, I just made another copy > of the kernel file, and it booted fine from that. I'm thinking it's > something to do with the way the original file is layed out on disk, and > grub w/ reiser4 is having trouble with it. do you still fail to boot with that kernel? would you run: debugfs.reiser4 -P | bzip2 -c > .bz2 on which the kernel file sits in and provide it to me for downloading. Then I will be able to debug the problem. > What's the best way to read off the meta-data for just that one file? > I've wanted to contribute something to Reiser4 development for a while > now. grub debugging is needed here, if libreiser4 reads the file correctly. probably reiser4progs/demos/busy, the 'cp' command, can reveal the problem too. > Perhaps I can figure out what's causing this boot problem and fix > it. it would be probably better to check first that the problem is not fixed yet. -- Vitaly
Re: need opinions from sysadmins on where reiser4progs should install
On Monday 21 November 2005 10:09, Hans Reiser wrote: > Philippe GramoullИ wrote: > > >Hello, > > > >On Sun, 20 Nov 2005 05:07:23 +0100 > >rvalles <[EMAIL PROTECTED]> wrote: > > > > | When I run make install on something and haven't specified a prefix on > > | configure, I expect /usr/local to be used. If I wanted /, I'd have > > | specified that on configure time. If it installed in / by default, it > > | would, often, hit the "sacred package-system managed area" of the VFS > > | tree annoying people like me to a very great extend, so please don't. > > > >While i totally agree with you for standard packages, well i based my choice > >on actual experience of the last past six years of use with reiserfs V3. > > > >I can't remember how many times i heard Namesys team say " Install the latest > >& greatest reiserfsck", how many times distro thought they knew reiserfsprogs > >internals better than Namesys and customized it to the point where it would > >eventually break. > > > >Of course, i can live with a manual install of reiser(fs|4)progs, so i don't > >really mind, but talking of support, it can make quite a difference to > >Namesys > >in terms of support, and annoyance with bug reports that could have been > >easily > >avoided. > > > > > Ok, I propose the following: search the standard locations for where it > is currently, tell the user, ask the user if they want to rename those the proper service is already done in package managers. if one needs it, he can use one of them. > versions to *.old if the install of the new one succeeds, and then this breaks the installed software consistency and may screw the package manager up... > prompt for the install location with /sbin as the suggested default. I > think that unlike other user installed programs, fsck does not belong in > /usr/local. I think Philippe's point that old versions are dangerous is > quite valid. install to the system default through a system package manager; install to the local default from source to not break the system installed software consistency; provide a way to install where a user wants if he knows what he does and if he remembers what and how has been installed on a particular system; > >Final decision will still be Namesys call, but hopefully this whole thread > >gave > >them some valuable input to make the best decision. > > > >Thanks, > > > >Philippe > > > -- Vitaly
Re: reiserfsck --rebuild-tree failure
On Wednesday 16 November 2005 20:27, iv wrote: > i'm following an advice to send a bug report about failed reiserfsck > --rebuild-tree found at http://www.namesys.com/faq.html#rebuild-tree. > i tried to compile the newest reiserfsprogs-3.6.15-pre1 but it fails use reiserfsprogs-3.6.19.tar.gz from ftp.namesys.com/pub/reiserfsprogs/ please > while doing "make": make.log. > so i run reiserfsck from a package (reiserfsck 3.6.13-pre1 (2003 > www.namesys.com)). it also failed: fsck.log. > i've got a lot of error massages in kern.log: kern.log. > obvious, there are badblocks: badblocks.log. check out www.namesys.com/bad-block-handling.html > i still can read from damaged partition. when i run `strings /dev/hdc3` > i get plently of text. > the question is if there is a way to mount the partition. > thanks in advance. > ivan matviyuk. > > -- Vitaly
Re: reiserfstune: block allocator is not defined
Hi,
try the attached patch please.
On Friday 21 October 2005 12:44, Vladimir V. Saveliev wrote:
> Hello
>
> Konstantin Mьnning wrote:
> > Hi!
> >
> > Just tried to add some badblocks like this:
> >
> > reiserfstune -b /tmp/badblocklist /dev/hda5
> >
> > and I get the error:
> >
> >
> > block allocator is not defined
> >
> > Aborted
> >
> >
> > The same when I try it with -B. As this message means nothing to me, has
> > somebody any idea what the problem might be? The man pages and
> > interestingly a web search gave me nothing about it. Or is reiserfstune
> > not to be used for adding bad blocks to the fs?
>
> reiserfstune is supposed to be use for that. You encountered reiserfstune bug.
> We are working on a fix.
>
>
>
--
Vitaly
diff -rup ./reiserfsprogs-3.6.19/reiserfscore/reiserfslib.c ./reiserfsprogs-3.6.19-2/reiserfscore/reiserfslib.c
--- ./reiserfsprogs-3.6.19/reiserfscore/reiserfslib.c 2005-10-21 18:42:23.088825144 +0400
+++ ./reiserfsprogs-3.6.19-2/reiserfscore/reiserfslib.c 2005-10-21 19:01:46.558950800 +0400
@@ -1346,6 +1346,24 @@ void mark_badblock(reiserfs_filsys_t *fs
pathrelse (badblock_path);
}
+static int reiserfs_alloc_blocks (reiserfs_filsys_t * fs,
+ unsigned long *blknr,
+ unsigned long start,
+ int count)
+{
+int i;
+
+for (i = 0; i < count; i ++) {
+ blknr[i] = 0;
+ if (reiserfs_bitmap_find_zero_bit(fs->fs_bitmap2, blknr + i))
+ die ("%s: failed to allocate a block.", __FUNCTION__);
+
+ reiserfs_bitmap_set_bit(fs->fs_bitmap2, blknr[i]);
+}
+
+return CARRY_ON;
+}
+
void add_badblock_list (reiserfs_filsys_t * fs, int replace) {
struct tree_balance tb;
struct path badblock_path;
@@ -1372,7 +1390,8 @@ void add_badblock_list (reiserfs_filsys_
set_type (KEY_FORMAT_2, &badblock_ih.ih_key, TYPE_INDIRECT);
j = 0;
-
+fs->block_allocator = reiserfs_alloc_blocks;
+
/* insert all badblock pointers */
for (i = 0; i < fs->fs_badblocks_bm->bm_bit_size; i++) {
int retval;
Re: Could reiserfsprogs display volume labels when doing fsck upon boot?
On Saturday 15 October 2005 16:19, Yiannis Mavroukakis wrote:
> Vitaly Fertman wrote:
>
> >On Friday 14 October 2005 16:07, Raymond A. Meijer wrote:
> >
> >
> >>On Friday 14 October 2005 15:07, Vitaly Fertman wrote:
> >>
> >>[...]
> >>
> >>
> >>
> >>>ok, I will add it.
> >>>
> >>>
> >>Vitaly, is it possible to add labels to Reiser4 filesystems AFTER mkfs,
> >>or only during mkfs?
> >>
> >>
> >
> >only on mkfs time for now.
> >
> >
> >
> For reiser4, would this do it?
> in function *reiser4_master_open(aal_device_t *device) in
> libreiser4/master.c
>
> /* Reiser4 master super block is not found on the device. */
> if (aal_strncmp(SUPER(master)->ms_magic, REISER4_MASTER_MAGIC,
> sizeof(REISER4_MASTER_MAGIC)) != 0)
> {
> aal_fatal("Wrong magic found in the master "
> "super block.");
> goto error_free_master;
> }
> /* Print volume label */
> aal_mess(reiser4_master_get_label(master));
>
> return master;
>
> error_free_master:
> aal_free(master);
> return NULL;
>
>
> Stab in the dark :P
I would put it into fsck after fs gets opened to not force
all callers to get this message.
however, 'fsck.reiser4 -a' does not perform any check yet
and does not even open fs.
--
Vitaly
Re: Reiserfsck can't fix FS
Hello Thomas! On Friday 14 October 2005 19:21, Thomas Raschbacher wrote: > Hi, > > I had to run reiserfsck on my usb hdd because there were some problems. > It told me to rebuild the tree (because I couldn't mount it I coudlnt' > backup things and I didn't have enough space (50GB) spare for a disk > image). > > attached my logfiles and (where i remembered to save it the stdout > output) > > It alwasy aborts at the same place. > > (i did the same for another partition and there after running reiserfsck > --rebuild-tree about 10 times it worked out ok but this one seems to be > a problem ..) > > reiserfsck 3.6.19 (2003 www.namesys.com) > Linux version 2.6.12-gentoo-r6 ([EMAIL PROTECTED]) (gcc version > 3.4.3-20050110 (Gentoo 3.4.3.20050110-r2, ssp-3.4.3.20050110-0, > pie-8.7.7)) #1 Thu Jul 21 20:21:20 BST 2005 > (i can provide kernel config file if needed) > > Please let me know if ther'es anything I can do as there's quite a bit > of data on that drive. it is possible to check how reiserfsck works, you can extract the fs metadata and fsck them on another compter. this does not require you to have 50M as there are not real data: debugreiserfs -p /dev/discs/disc2/part6 | bzip2 -c > part6.bz2 go to another computer: touch part6.image bunzip2 -c part6.bz2 | debugreiserfs -u part6.image reiserfsck --rebuild-tree part6.image -l logfile if it finishes successfully, the problem is in your hardware. As the same block number repeats and there is also a failed block read, the problem is likely to be IO related. it fsck fails on your metadata, I would like to have a look at part6.bz2. -- Vitaly
Re: Could reiserfsprogs display volume labels when doing fsck upon boot?
On Friday 14 October 2005 16:07, Raymond A. Meijer wrote: > On Friday 14 October 2005 15:07, Vitaly Fertman wrote: > > [...] > > > ok, I will add it. > > Vitaly, is it possible to add labels to Reiser4 filesystems AFTER mkfs, > or only during mkfs? only on mkfs time for now. -- Vitaly
Re: Could reiserfsprogs display volume labels when doing fsck upon boot?
On Friday 14 October 2005 13:40, Wiktor Wandachowicz wrote: > Recently I've changed a filesystem on one of my patitions from ext3 to > reiserfs 3.6. > > All of my partitions have labels (hint: "mke2fs -L") so at boot I can easily > see > which partitions are fsck-ed. So while reformatting my last partition > /dev/hda8 > as reiserfs 3.6, I've labeled it too (hint: "mkreiserfs -l"). > > Alas, upon boot reiserfsck never displays a volume label set this way, only: > > Reiserfs super block in block 16 on 0x307 of format 3.6 with standard journal > > While ext2/ext3 fsck displays a neat message for every partition it checks, > like: > > BOOT: clean, 62/297256 files, 60311/594405 blocks > > > So, I wanted to ask you: is adding such a functionality to reiserfsck a good > idea? > I've tried to add it myself and it turned out to be four lines in one source > file > (well, two lines actually doing the job, because one line is a comment and > another > one contains a curly bracket). I have a small patch against > reiserfsprogs-3.6.19 > (applicable to the 3.6.18 and 3.6.17) ready to be sent. > > Now my reiserfsck tests if volume label exists, and in such case displays it > like: > > SPARE: Reiserfs super block in block 16 on 0x307 of format 3.6 with standard > journal > > > And yes, I know it's cosmetic :-) > > But for me it's nice to have. This way my system behaves in a more consistent > way. > Maintainers I asked from my distribution suggested to ask my question at the > source. > What is your opinion then, reiserfs people? ok, I will add it. -- Vitaly
Re: reiserfsck --rebuild-tree fails with "out of space"
Hello On Saturday 08 October 2005 04:21, Harry Edmon wrote: > Today 04:21:37 > > > A disk I am trying to fix fails a "reiserfsck --rebuild-tree" with the > message "out of space". I have enclosed the log, and the output to the > terminal. The system is running Debian "sarge" with all released > patches. Kernel is 2.6.8. Reiserfsck is 3.6.19. No disk errors in any > log files. > > > > condense:~# reiserfsck --logfile /var/tmp/reiser.log --rebuild-tree /dev/hdg1 > reiserfsck 3.6.19 (2003 www.namesys.com) > > Will rebuild the filesystem (/dev/hdg1) tree > Will put log info to '/var/tmp/reiser.log' > > Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes > Replaying journal.. > Reiserfs journal '/dev/hdg1' in blocks [18..8211]: 0 transactions replayed > ### > reiserfsck --rebuild-tree started at Fri Oct 7 15:46:17 2005 > ### > > Pass 0: > Loading on-disk bitmap .. ok, 61048992 blocks marked used > Skipping 10074 blocks (super block, journal, bitmaps) 61038918 blocks will be > read > 0%20%40%60%.. > lef left 0, 13223 > /secccsec > "r5" hash is selected > Flushing..finished > Read blocks (but not data blocks) 61038918 > Leaves among those 141109 > - leaves all contents of which could not be saved and > deleted 5 > Objectids found 414533 > > Pass 1 (will try to insert 141104 leaves): > Looking for allocable blocks .. finished > 0%20%40%60%80%Not enough allocable blocks, > checking bitmap...there are 1 allocable blocks, btw you need to get a larger partition, dd hdg1 there, run 'reiserfsck --rebuild-sb' on the copy to enlarge the fs size and after that run 'reiserfsck --rebuild-tree' on it. or you can enlarge the existent hdg1. Note: some disk space will be added to the current partition, if there was a reiserfs before, that fs metadata will be mixed with the current fs. to avoid it, zero the added disk space first (dd if=/dev/zero ...) -- Vitaly
Re: Unable to rebuild bitmap.
On Wednesday 05 October 2005 19:10, Lance Reed wrote: > So, is this problem fixed in Reiserfs4 ? reiser4 is absolutely different fs written from the scratch, it is in the mm kernel only yet. regarding the reiserfs, there is a patch that solves the problem, not accepted though, if you tell me the kernel number you would like to work with I can send it to you. > I can build a new host and use reiserfs4 if this will solve my problem, > and just copy the data. I just want to make sure I can make 16TB files > systems if I need to. > > Thanks so much for all your help and information! > > > Lance > > Vitaly Fertman wrote: > > >On Wednesday 05 October 2005 01:46, Lance Reed wrote: > > > > > >>Thanks for the info! > >> > >>I have tried this. I made the new 3.6.19 code. > >>Ran a --rebuild-sb, seemed better. When I try to run a --check, > >>it still says that it can not read the bitmap. > >>So, is this problem with the reiserfs code in the kernel I am booting? > >>I thought that we could get up to 16 TB. > >> > >> > > > >as I have mentioned the current code supports up to the 8Tb only. > >if you need a larger fs you have to patch both kernel and progs. > > > > > > > >>Is there a way to force a rebuild of the superblock. > >>maybe delete it with dd at offset 64 ? > >>something like this maybe ? > >> > >>dd if=/dev/zero of=/dev/VG01/lvol0 bs=1024 seek=64 count=1 > >>(http://lists.suse.com/archive/suse-linux-e/2003-Dec/1731.html) > >> > >>Then rebuild the bitmap? > >>This might be a bit crazy? > >> > >>Anybody got any ideas? > >> > >>Thank you so much for the assistance! > >> > >>Lance > >> > >> > >>livestore2:~ # reiserfsck --check /dev/VG01/lvol0 > >>Do you want to run this program?[N/Yes] (note need to type Yes if you > >>do):Yes > >>### > >>reiserfsck --check started at Tue Oct 4 21:36:46 2005 > >>### > >>Replaying journal.. > >>Reiserfs journal '/dev/VG01/lvol0' in blocks [18..8211]: 0 transactions > >>replayed > >>reiserfs_open_ondisk_bitmap: wrong either bitmaps number, > >>count of blocks or blocksize, run with --rebuild-sb to fix it > >>reiserfsck: Could not open bitmap > >> > >> > >>livestore2:~ # reiserfsck --fix-fixable /dev/VG01/lvol0 > >>Do you want to run this program?[N/Yes] (note need to type Yes if you > >>do):Yes > >>### > >>reiserfsck --fix-fixable started at Tue Oct 4 21:38:34 2005 > >>### > >>Replaying journal.. > >>Reiserfs journal '/dev/VG01/lvol0' in blocks [18..8211]: 0 transactions > >>replayed > >>reiserfs_open_ondisk_bitmap: wrong either bitmaps number, > >>count of blocks or blocksize, run with --rebuild-sb to fix it > >>reiserfsck: Could not open bitmap > >> > >> > >>Vitaly Fertman wrote: > >> > >> > >> > >>>On Tuesday 04 October 2005 22:27, Lance Reed wrote: > >>> > >>> > >>> > >>> > >>>>I seem to be stuck in a catch 22 and can not seem to rebuild a bitmap. > >>>>reiserfsck --check says the bitmap is bad. > >>>>reiserfsck --rebuild-sb says it is ok. > >>>> > >>>>I do seem some errors but can not seem to repair them.. > >>>>"Fs state field: 0x1: > >>>>some corruptions exist." > >>>> > >>>>If I mount the filesystem and try to write to it, I get a kernel oops. > >>>> > >>>>The Filesystem has recently been increased to just under 10 TB. > >>>> > >>>>Anybody have any ideas? > >>>> > >>>> > >>>> > >>>> > >>>this is a known problem revealed recently. the reiserfs has the 16 > >>>bits bitmap couter, so the maximum fs size is (0x * BlockSize * > >>>8 * BlockSize) = 8T for 4k blocksize. > >>> > >>> > >>> > >>> > >>> > >>>>TIA. > >>>> > >>>>Lance > >>>> > >>>>2 2.6.4-52-smp #1 SMP Wed Apr 7 02:11:20 UTC 2004 i686 i686 i386 GNU/Linux > >>>>SuSE Linux 9.1 (i586) > >>>>VERSION = 9.1 > >>>>reiserfs-3.6.13-24 > >>>> > >>>> > >>>> > >>>> > >>>please update the progs to the latest (3.6.19) version. > >>> > >>> -- Vitaly
Re: Unable to rebuild bitmap.
On Wednesday 05 October 2005 01:46, Lance Reed wrote: > Thanks for the info! > > I have tried this. I made the new 3.6.19 code. > Ran a --rebuild-sb, seemed better. When I try to run a --check, > it still says that it can not read the bitmap. > So, is this problem with the reiserfs code in the kernel I am booting? > I thought that we could get up to 16 TB. as I have mentioned the current code supports up to the 8Tb only. if you need a larger fs you have to patch both kernel and progs. > Is there a way to force a rebuild of the superblock. > maybe delete it with dd at offset 64 ? > something like this maybe ? > > dd if=/dev/zero of=/dev/VG01/lvol0 bs=1024 seek=64 count=1 > (http://lists.suse.com/archive/suse-linux-e/2003-Dec/1731.html) > > Then rebuild the bitmap? > This might be a bit crazy? > > Anybody got any ideas? > > Thank you so much for the assistance! > > Lance > > # reiserfsck -V > reiserfsck 3.6.19 (2003 www.namesys.com) > > livestore2:~ # reiserfsck --rebuild-sb /dev/VG01/lvol0 > Do you want to run this program?[N/Yes] (note need to type Yes if you > do):Yes > Reiserfs super block in block 16 on 0xfd00 of format 3.6 with standard > journal > Count of blocks on the device: 2594963456 > Number of bitmaps: 13656 > Blocksize: 4096 > Free blocks (count of blocks - used [journal, bitmaps, data, reserved] > blocks): 919312864 > Root block: 23854440 > Filesystem is clean > Tree height: 5 > Hash function used to sort names: "r5" > Objectid map size 2, max 972 > Journal parameters: > Device [0x0] > Magic [0x7c282a2f] > Size 8193 blocks (including 1 for journal header) (first block 18) > Max transaction length 1024 blocks > Max batch size 900 blocks > Max commit age 30 > Blocks reserved by journal: 0 > Fs state field: 0x0: > sb_version: 2 > inode generation number: 51677 > UUID: dfc4b601-40b9-44e4-b246-3cb4c96ac152 > LABEL: > Set flags in SB: > ATTRIBUTES CLEAN > > Super block seems to be correct > > livestore2:~ # reiserfsck --check /dev/VG01/lvol0 > Do you want to run this program?[N/Yes] (note need to type Yes if you > do):Yes > ### > reiserfsck --check started at Tue Oct 4 21:36:46 2005 > ### > Replaying journal.. > Reiserfs journal '/dev/VG01/lvol0' in blocks [18..8211]: 0 transactions > replayed > reiserfs_open_ondisk_bitmap: wrong either bitmaps number, > count of blocks or blocksize, run with --rebuild-sb to fix it > reiserfsck: Could not open bitmap > > > livestore2:~ # reiserfsck --fix-fixable /dev/VG01/lvol0 > Do you want to run this program?[N/Yes] (note need to type Yes if you > do):Yes > ### > reiserfsck --fix-fixable started at Tue Oct 4 21:38:34 2005 > ### > Replaying journal.. > Reiserfs journal '/dev/VG01/lvol0' in blocks [18..8211]: 0 transactions > replayed > reiserfs_open_ondisk_bitmap: wrong either bitmaps number, > count of blocks or blocksize, run with --rebuild-sb to fix it > reiserfsck: Could not open bitmap > > > Vitaly Fertman wrote: > > >On Tuesday 04 October 2005 22:27, Lance Reed wrote: > > > > > >>I seem to be stuck in a catch 22 and can not seem to rebuild a bitmap. > >>reiserfsck --check says the bitmap is bad. > >>reiserfsck --rebuild-sb says it is ok. > >> > >>I do seem some errors but can not seem to repair them.. > >>"Fs state field: 0x1: > >> some corruptions exist." > >> > >>If I mount the filesystem and try to write to it, I get a kernel oops. > >> > >>The Filesystem has recently been increased to just under 10 TB. > >> > >>Anybody have any ideas? > >> > >> > > > >this is a known problem revealed recently. the reiserfs has the 16 > >bits bitmap couter, so the maximum fs size is (0x * BlockSize * > >8 * BlockSize) = 8T for 4k blocksize. > > > > > > > >>TIA. > >> > >>Lance > >> > >>2 2.6.4-52-smp #1 SMP Wed Apr 7 02:11:20 UTC 2004 i686 i686 i386 GNU/Linux > >>SuSE Linux 9.1 (i586) > >>VERSION = 9.1 > >>reiserfs-3.6.13-24 > >> > >> > > > >please update the progs to the latest (3.6.19) version. > > > > > > > >>lvm2-2.00.09-12 > >> > >> > >>livestore2:~ # reiserfsck --check /dev/VG01/lvol0 > >>.. > >>Replaying journal.. > >>Reiserfs journal '/dev/VG01/lvol0' in blocks [18..8211]: 0 transactions > >>replayed > >>re
Re: reiserfsprogs spec file bug report
On Wednesday 05 October 2005 01:15, Dan Pritts wrote: > Hi, Hello! > I just downloaded & built reiserfsprogs-3.6.19 on Red Hat EL 4. > > This has a newer version of RPM than you've designed your SPEC > file for, and suffers from problems described in these two URLs: > > 1) http://www.rpm.org/hintskinks/debuginfo/ > 2) http://www.rpm.org/hintskinks/unpackaged-files/ > > 1) Before anything happens, I get: > error: Package already exists: %package debuginfo > > This is easily addressed by changing "%install" in a comment to "% install" > > 2) At the end of the build process, i get: > >RPM build errors: > Installed (but unpackaged) file(s) found: >/rpm-filelist > > It looks like you're using this rpm-filelist file as a temporary file > to show what should go into the RPM. Not clear why you store that > information in a temp file instead of the spec file but i'm sure you > have your reasons. > > The rpm.org site suggests removing any such non-packaged files at the > end of the %install phase, which would probably not work given what this > file is for. Perhaps moving this a file to /tmp is a better way to go > but there may be reasons not to do this, either. > > > i downloaded the equivalent SRPM from fedora core 4 and it "just built" > using their spec file so i didn't put much more effort into fixing the > problem myself, but i thought you'd be interested to know about this. yes, thank you, I will check it. -- Vitaly
Re: Unable to rebuild bitmap.
On Tuesday 04 October 2005 22:27, Lance Reed wrote: > I seem to be stuck in a catch 22 and can not seem to rebuild a bitmap. > reiserfsck --check says the bitmap is bad. > reiserfsck --rebuild-sb says it is ok. > > I do seem some errors but can not seem to repair them.. > "Fs state field: 0x1: > some corruptions exist." > > If I mount the filesystem and try to write to it, I get a kernel oops. > > The Filesystem has recently been increased to just under 10 TB. > > Anybody have any ideas? this is a known problem revealed recently. the reiserfs has the 16 bits bitmap couter, so the maximum fs size is (0x * BlockSize * 8 * BlockSize) = 8T for 4k blocksize. > TIA. > > Lance > > 2 2.6.4-52-smp #1 SMP Wed Apr 7 02:11:20 UTC 2004 i686 i686 i386 GNU/Linux > SuSE Linux 9.1 (i586) > VERSION = 9.1 > reiserfs-3.6.13-24 please update the progs to the latest (3.6.19) version. > lvm2-2.00.09-12 > > > livestore2:~ # reiserfsck --check /dev/VG01/lvol0 > .. > Replaying journal.. > Reiserfs journal '/dev/VG01/lvol0' in blocks [18..8211]: 0 transactions > replayed > reiserfs_open_ondisk_bitmap: wrong either bitmaps number, > count of blocks or blocksize, run with --rebuild-sb to fix it > reiserfsck: Could not open bitmap > livestore2:~ # reiserfsck --rebuild-sb /dev/VG01/lvol0 > > Will check superblock and rebuild it if needed > Will put log info to 'stdout' > > Do you want to run this program?[N/Yes] (note need to type Yes if you > do):Yes > Reiserfs super block in block 16 on 0xfd00 of format 3.6 with standard > journal > Count of blocks on the device: 2594701312 > Number of bitmaps: 13648 > Blocksize: 4096 > Free blocks (count of blocks - used [journal, bitmaps, data, reserved] > blocks): 919312864 > Root block: 23854440 > Filesystem is clean > Tree height: 5 > Hash function used to sort names: "r5" > Objectid map size 2, max 972 > Journal parameters: > Device [0x0] > Magic [0x7c282a2f] > Size 8193 blocks (including 1 for journal header) (first block 18) > Max transaction length 1024 blocks > Max batch size 900 blocks > Max commit age 30 > Blocks reserved by journal: 0 > Fs state field: 0x1: > some corruptions exist. > sb_version: 2 > inode generation number: 51677 > UUID: dfc4b601-40b9-44e4-b246-3cb4c96ac152 > LABEL: > Set flags in SB: > ATTRIBUTES CLEAN > > Super block seems to be correct > > If I mount and try try to write to the filesystem. > > Oct 3 20:25:30 livestore2 kernel: Unable to handle kernel NULL pointer > dereference at virtual address 0c20 > Oct 3 20:25:30 livestore2 kernel: printing eip: > Oct 3 20:25:30 livestore2 kernel: f90a52aa > Oct 3 20:25:30 livestore2 kernel: *pde = > Oct 3 20:25:30 livestore2 kernel: Oops: [#1] > Oct 3 20:25:30 livestore2 kernel: SMP > Oct 3 20:25:30 livestore2 kernel: CPU:1 > Oct 3 20:25:30 livestore2 kernel: EIP: > 0060:[__crc_device_suspend+2410267/2709224]Not tainted > Oct 3 20:25:30 livestore2 kernel: EIP:0060:[]Not tainted > Oct 3 20:25:30 livestore2 kernel: EFLAGS: 00010246 (2.6.4-52-smp) > Oct 3 20:25:30 livestore2 kernel: EIP is at > scan_bitmap_block+0x1da/0x480 [reiserfs] > Oct 3 20:25:30 livestore2 kernel: eax: ebx: 0c20 ecx: > 00f8 edx: > Oct 3 20:25:30 livestore2 kernel: esi: f9376310 edi: 0c20 ebp: > esp: efadd930 > Oct 3 20:25:30 livestore2 kernel: ds: 007b es: 007b ss: 0068 > Oct 3 20:25:30 livestore2 kernel: Process rsync (pid: 4193, > threadinfo=efadc000 task=f5f880b0) > Oct 3 20:25:30 livestore2 kernel: Stack: 0b01 cdc2b380 > c0143a56 6100 f9383118 > Oct 3 20:25:30 livestore2 kernel: f5c65800 efadd9e4 > da62 efaddf30 f90c14fa 0080 da62 > Oct 3 20:25:30 livestore2 kernel:8000 f5c65800 0001 > f90a6105 8000 0001 0001 > Oct 3 20:25:30 livestore2 kernel: Call Trace: > Oct 3 20:25:30 livestore2 kernel: [find_get_page+22/64] > find_get_page+0x16/0x40 > Oct 3 20:25:30 livestore2 kernel: [] find_get_page+0x16/0x40 > Oct 3 20:25:30 livestore2 kernel: > [__crc_device_suspend+2525547/2709224] > internal_insert_childs+0x1fa/0x210 [reiserfs] > Oct 3 20:25:30 livestore2 kernel: [] > internal_insert_childs+0x1fa/0x210 [reiserfs] > Oct 3 20:25:30 livestore2 kernel: > [__crc_device_suspend+2413942/2709224] > reiserfs_allocate_blocknrs+0x3e5/0xc89 [reiserfs] > Oct 3 20:25:30 livestore2 kernel: [] > reiserfs_allocate_blocknrs+0x3e5/0xc89 [reiserfs] > Oct 3 20:25:30 livestore2 kernel: > [__crc_device_suspend+2481484/2709224] get_far_parent+0x15b/0x350 > [reiserfs] > Oct 3 20:25:30 livestore2 kernel: [] > get_far_parent+0x15b/0x350 [reiserfs] > Oct 3 20:25:30 livestore2 kernel: > [__crc_device_suspend+2485508/2709224] get_empty_nodes+0xf3/0x1a0 > [reiserfs] > Oct 3 20:25:30 livestore2 kernel: [] > get_empty_nodes+0xf3/0x1
Re: Full of surprises - A reiser4 story from userland
On Wednesday 28 September 2005 21:57, Fionn Behrens wrote: > On Mi, 2005-09-28 at 20:40 +0400, Vitaly Fertman wrote: > > > remember that reiser4progs-1.0.4 supports both formats, in other words > > having the format updated to the new one, you are able to use new > > kernelonly. If you want to move back to 2.6.10, you have to build-fs > > with 1.0.3 version or reiser4progs. > > Do I get this right? I had reiser4progs 1.0.4 and it should already know > the new format? If what you say is right then fsck should have not > complained about an error in the first place AND I still should not be > able to boot with the old kernel any more after --build-fs. > But it found an error. And I ran --build-fs with it. And now I am using > the old kernel again and it does NOT complain about errors any more. > (except for that flag we discussed already). > > Pardon me, I am confused. hm, before writing that I had checked 1.0.4 progs and thought there was another older fsck you could run that time, but I have just double checked it and have found that 1.0.4 version I looked into was changed a bit. You are right, 1.0.4 works with the old format. and if you run it again with --check, you get rid of the ERROR flag in the super block. -- Vitaly
Re: Full of surprises - A reiser4 story from userland
On Wednesday 28 September 2005 19:28, Fionn Behrens wrote: > On Mi, 2005-09-28 at 18:25 +0400, Vitaly Fertman wrote: > > > > 2.6.11 refused to boot the > > > root partition, claiming that there were an inconsistency in the FS. > > > > the disk format got new parameters and old kernels cannot understand it > > right. > > Ah, I see. So maybe it would be a good idea if the new fs version would > put up a big fat warning to syslog when it detects a partition written > by a previous version, telling the user that he is about to break > compatibility to his older version (and that the must upgrade userland > tools, too!) > > > > Sep 28 08:44:20 rtfm kernel: WARNING: wrong pset member (11) for 42 > > > Sep 28 08:44:20 rtfm kernel: WARNING: unused space in inode 42 > > > which fsck version? > > 1.0.4 > > > > the man page said that this would be read-only. > > > > it says: > > " --check > > the default action checks the consistency and reports, but does not > > repair any corruption that it finds. This option may be used on a > > read-only file system mount. > > " > > it does not mean 100% read-only check. > > Okay, you sound a bit like a lawyer, but: you right me wrong. > > > > There was my fourth surprise: This fsck thing had LIED to me; it was not > > > read-only. > > > > why do you think --build-fs is read-only? > > Had not gone --build-fs yet. This was still about --check. > > > > It may have checked the fs read-only but it must have > > > treacherously flipped some "error" bit somewhere on disk > > > > Warning, mounting filesystem with fatal errors, forcing read-only mount > > > (followed by the error from above) > > > > do you see anything relevant in the syslog? > > That line was in the syslog. ok, the flag that fs contains errors is indeed cleared only with --check with all reiser4progs untill 1.0.5, the later is able to do it with any options. Thus another --check run would clear the flag. However 'the error from above' that is 'WARNING: wrong pset member (11) for 42' is possible with the old kernel only. remember that reiser4progs-1.0.4 supports both formats, in other words having the format updated to the new one, you are able to use new kernel only. If you want to move back to 2.6.10, you have to build-fs with 1.0.3 version or reiser4progs. > > > So much for --check being just a check. I grabbed a book and lost about > > > two more precious working hours running the --build-fs thing. > > > you need to clarify what reiser4progs version you are running. > > 1.0.5 fixes the fs to the letest format, which is needed for 2.6.13. > > 1.0.3 to the 2.6.10's one. > > 1.0.4 . As I am now back on 2.6.11, I guess I should not upgrade to > 1.0.5 or would that not do harm anyway? 1.0.5 is 1.0.4 + bugfixes. > thanks for answering! > > kind regards, > Fionn -- Vitaly
Re: Full of surprises - A reiser4 story from userland
On Wednesday 28 September 2005 17:40, Fionn Behrens wrote: > > Hello all, Hello > I just wanted to tell along a bit about my recent experiences with > reiserfs. I have been using reiser3.[56] without any glitch for more > than five years and when I got a new notebook last year, I decided to > give reiser4 a try. There even was a handy kernel patch package > available in debian! How nice. A few bencharks proved my choice was > right. Over the last 12 months I was very happy with it - no sign of a > problem and pretty fast operation on 2.6.10 and 11. > > A few days ago I decided to upgrade to 2.6.13 because I need it for > development at work. Having heard about the discussions around reiser4 > kernel integration I supposed it should be quite stable now and that it > may even have improved some more. I also expected it to be readily > available as a kernel patch for everyone to try. > > There was my first surprise: It was not! I spent quite some time > searching around and finally found that seemingly the only way to get > reiser4 for the latest kernel were a dozen and a half reiser4* patches > from mm. Their proper sequence of application also is up to the > technically interested user. > Why you request a software to be integrated into Linux while you dont > even provide an official patch download for the very kernel version you > want it in, is beyond my comprehension. > > Well, since I needed 2.6.13 and my root partition already was reiser4 I > had to take things like they were. I spent another hour applying those > patches and getting around some minor problems doing so. Finally, there > was my shiny new 2.6.13 with reiser4. > > But alas, the next surprise was not far away. Trying to suspend my > notebook now resulted in some reiser4 kernel processes going postal: > > PID USER PR SHR S %CPU %MEMTIME+ COMMAND > 984 root 25 0 R 25.3 0.0 0:23.62 ktxnmgrd:dm-0:t > 3246 root 25 0 R 24.3 0.0 0:23.54 ktxnmgrd:hda4:t > 985 root 25 0 R 23.3 0.0 0:23.61 ent:dm-0. > 3247 root 25 0 S 23.3 0.0 0:23.60 ent:hda4. > > The load went up to 8 and my computer became the most expensive heater > on the block. Reboot unavoidable. Maybe reiser4 had not improved that > much. A short check on the net just popped a few posts about recent > reiser4 being "a turkey" and that someone should put up a warning > somewhere (DAMN YES YOU SHOULD) but no solution. > I decided to go back to 2.6.11 before any more bad things happen. > > Third surprise: they had already happened. 2.6.11 refused to boot the > root partition, claiming that there were an inconsistency in the FS. the disk format got new parameters and old kernels cannot understand it right. > Sep 28 08:44:20 rtfm kernel: WARNING: wrong pset member (11) for 42 > Sep 28 08:44:20 rtfm kernel: reiser4[mount(840)]: init_inode_static_sd > (fs/reiser4/plugin/item/static_stat.c:283)[nikita-631]: > Sep 28 08:44:20 rtfm kernel: WARNING: unused space in inode 42 > > I know the disk is ok and I had not had a crash of any sort (the freaked > out kernel from above seemed to shut down properly at least). So I > probed this a bit further: > > trying 2.6.13 reiser4: booting without a warning. > trying 2.6.11 again: error, error, no go > trying 2.6.13 once more: booting nicely > trying 2.6.11 finally: error again. > > Okay, I'd call this another surprise. I just did not know whether there > actually was a problem or not! So I decided to give fsck a shot (on which fsck version? > 2.6.11 - I had somewhat lost my belief in recent reiser4 code). > I just ran in with --check, because the man page said that this would be > read-only. it says: " --check the default action checks the consistency and reports, but does not repair any corruption that it finds. This option may be used on a read-only file system mount. " it does not mean 100% read-only check. > It found this: > > FSCK: Node (2196341), item (0), [29:1(SD):0:2a:0]: does not look like a > valid SD > plugin set extention: wrong pset member count detected (12). > FSCK: Node (2196341), item (0), [29:1(SD):0:2a:0]: does not look like a > valid stat data. > FSCK: Node (2196341), item (0), [29:1(SD):0:2a:0]: broken item found. > FSCK: Node (2196341): the node is broken. Pointed from the node > (2196340), item (0), unit (0). The whole subtree is skipped. > > Of course, as a user, I don't have the slightest idea what this means. > "The whole subtree is skipped" sounded worryingly lossy, however. > At the end of the run, fsck told me I had to rerun it with --build-fs. > Now that sounded pretty heavy. I still have some real work to do and I > already had lost several working hours to this and was not very willing > to do so right now. > So I decided to take advantage of the now proven fact that > REISER4-2.6.13 DOES NOT RECOGNIZE ITS SELF-MADE DAMAGE and give it > another go for today (I made a backup the other day anyway), save my > work
Re: Identify Superblock
On Thursday 22 September 2005 05:11, Markus Hiereth wrote: > Hello, > > as YaST and fdisk showed different output for the partions of my > hard-disk, I got confused and lost the correct start point for my > partition /dev/hda5. > > Recreation of superblocks by reiserfsck --rebuild-sb creates a > superblock, but afterwards, --rebuild-tree terminates with a message > that no metadata can be found. > > Now I am trying to find out which of the blocks is the superblock. I > made first attempts with > a) copying using the command dd and then > b) use of grep ReIsEr2Fs as search string on blocks of 4096 bytes. > > Techical background information > reiserfs: 3.6.9 > Kernel: 2.4.21 > Hard disk: Maxtor 9084006 > > Is this a possible approach? yes, although there are many SB copies in the journal area. the magic string of the correct SB is on 64K + 52 bytes offset. if you need our assistance here please visit: www.namesys.com/support.html > Thanks for Your help > Markus Hiereth > > Braunschweig, Germany > > -- Thanks, Vitaly Fertman
Re: I request inclusion of reiser4 in the mainline kernel
On Wednesday 21 September 2005 07:05, Hans Reiser wrote: > Ric Wheeler wrote: > > > Hans Reiser wrote: > > > >> Ric Wheeler wrote: > >> > >> > >>> As an earlier thread on lkml showed this summer, we still have a long > >>> way to go to getting consistent error semantics in face of media > >>> failures between the various file systems. I am not sure that we even > >>> have consensus on what that default behavior should be between > >>> developers, so image how difficult life is for application writers who > >>> want to try to ride through or write automated "HA" recovery scripts > >>> for systems with large numbers of occasionally flaky IO devices ;-) > >> > >> > >> > >> If you'd like to form a committee to standardize these things, I will > >> ask Vitaly to work with you on that committee, and to have ReiserFS3+4 > >> conform to the standards that result. > >> > >> Hans > > > > > > I am not a big fan of formal committees, but would be happy to take > > part in any effort to standardize, code and test the result... I would be happy to take part in it too. > > ric > > > > > > > The committee could simply exchange a set of emails, and agree on > things. I doubt it needs to get all complicated. I suggest you contact > all the folks you want to be consistent with each other, send us an > email asking us to all try to work together, and then ask for proposals > on what we should all conform to. Distill the proposals, and then > suggest a common solution. With luck, we will all just say yes.:) -- Thanks, Vitaly Fertman
Re: I request inclusion of reiser4 in the mainline kernel
On Wednesday 21 September 2005 01:11, Theodore Ts'o wrote: > On Tue, Sep 20, 2005 at 12:18:46PM -0600, Jonathan Briggs wrote: > > > > I use Reiser3 and Reiser4 on all my systems and fsck has always worked > > even if it has been much slower than I would like. The only problems > > I've experienced have been on the same level as when an ext2/3 > > filesystem fsck dumps several directories of unlabeled files into lost > > +found. > > You've obviously never kept several dozen reiserfs filesystem images > (for use with Xen or User-Mode Linux) on a reiserfs filesystem, and > then had a hardware failure bad enough that the fsck had to try to > rebuild the b-tree, I take it? loop device XOR encryption for your images is the simple solution for reiserfs V3. -- Thanks, Vitaly Fertman
Re: --rebuild-tree Questions
On Tuesday 13 September 2005 01:40, Jeremy Brown [InfoSend] wrote: > Hi list, Hello Jeremy > I have an external SCSI disk array (Dell PowerVault 220s) and had > some problems altering it's configuration. I was attempting to add 2 > disks to the RAID-5 array, and in the process found that 3 of the 4 > disks I bought of identical brand and size were bad! > > After much toil and tribulation, I got the RAID to work by getting 2 > functioning disks in the SCSI disk array. However, without even > attempting to resize the partition or anything, I started > experiencing problems with the Reiser partition. Some files on the > FS are inaccessible with "Permission Denied" errors when I try to ls > in the directory. The errors in the log look like this: > > Sep 12 14:22:29 pdc kernel: ReiserFS: warning: is_tree_node: node > level 0 does not match to the expected one 1 > Sep 12 14:22:29 pdc kernel: ReiserFS: sdb1: warning: vs-5150: > search_by_key: invalid format found in block 1901161. Fsck? > Sep 12 14:22:29 pdc kernel: ReiserFS: sdb1: warning: vs-13070: > reiserfs_read_locked_inode: i/o failure occurred trying to find stat > data of [141946 595210 0x0 SD] > > However, about 95% of the data remains readable. But if we try to > overwrite or delete certain files on the fs, we get various errors. > Sometimes the kernel panics, sometimes Samba stops responding, etc... > > Anyways... I ran a reiserfsck --check on the partition, and it had > about 33 errors that it said needed the rebuild-tree option. But I > have two questions: > > 1. What is a ballpark success rate of this command? quite successful > Does it work more often than not? when fs gets corrupted. > Even if it put files into lost+found > directories, that would be fine with me. I'm just afraid of a total > failure of the operation. I do have the data backed up to LTO-2 > tape, but I consider restoration of all files on this partition from > tape as hopefully a last resort. > > 2. Most importantly: About how long can I expect the rebuild-tree > operation to take? I know there's no definitive answer for this, but > I've searched high and low for other people's results with this > command and no one has mentioned how long it took (other than a post > on this list earlier from someone who's command apparently failed). > The partition is 410GB of Ultra-160 SCSI. Again, I know an exact > figure isn't possible, but does anyone have a ballpark figure of what > I should expect? it depends on the amount of data kept on the fs and average file size, 3h-10h. > I'm sorry if I rambled or left off any important information, but TIA > for any help with these questions. I'd be happy to add any > information requested. > -- Thanks, Vitaly Fertman
Re: Strange problems/bugs with reiserfs and reiserfschk
On Wednesday 24 August 2005 01:30, Konstantin Münning wrote: > Hi Vitaly! > > Thank you for the reiserfsck 3.9.20. It in fact had different results on > that drive. I had it run in gdb (as I did with 3.6.19 to see what/where > the trouble may be) and the result is: > > (***snip***) > vpf-10680: The file [641222 641239] has the wrong block count in the > StatData (1528) - corrected to (1520) > vpf-10680: The file [641222 641241] has the wrong block count in the > StatData (47192) - corrected to (47168) > vpf-10680: The file [641222 641242] has the wrong block count in the > StatData (16624) - corrected to (16528) > > are_file_items_correct: All bytes we look for must be first items byte > (position 0). > > Program received signal SIGABRT, Aborted. > 0xe410 in __kernel_vsyscall () > (***snip***) > > Hmm... Ugly ;-). > > Vitaly Fertman wrote: > > > if some file item offsets are corrupted, fsck can work for too long on > > pass2. or it also can be a bug. I will send you a version of reiserfsprogs > > that has an optimization fix for former. if it fails email me and provide > > the metadata please: > > debugreiserfs -p | bzip2 -c > .bz2 > > Do you need the metadata or the full logfile or should I send you > something more/else for that? yes, metadata would be enough. -- Thanks, Vitaly Fertman
Re: Can one stop reiserfsck --rebuild-tree
On Monday 22 August 2005 18:32, Ricardo (Tru64 User) wrote: > Hi, > Checking reiserfs manpages...i dont see a mention of > the effects of killing --rebuild-tree process once in > progress. it is possible to lose data, when interrupting reiserfsck, however it depends on the rebuild stage: pass0, pass1 -- no problem; 2 -- internal tree is rebalanced intensively, the worst time to kill; semantic and lost&found passes -- it is posible to lose data as when a corruption is found, tree is rebalanced. thus than fewer corruptions present, than fewer rebalancings are performed, than lower chances to lose data. > Can this be suspended (ctrl ^Z)? yes, no problem. -- Thanks, Vitaly Fertman
Re: Error in reiserfsck 3.6.19
On Friday 19 August 2005 12:14, Adam McLellan wrote: > Unless I'm doing something wrong, there is an error in reiserfsck > 3.6.19. It's actually kind of a humourous error; it doesn't divide > correctly :-). I've been going through a somewhat lengthly process to > diagnose the problem with my reiserfs filesystem, and finally got to > the point where I'm ready to rebuild the superblock. Here's the > output: > > > ==> [EMAIL PROTECTED] reiserfsck --rebuild-sb /dev/md0 > ==> reiserfsck 3.6.19 (2003 www.namesys.com) > ==> > ==> * > ==> ** If you are using the latest reiserfsprogs and it fails ** > ==> ** please email bug reports to reiserfs-list@namesys.com, ** > ==> ** 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 check superblock and rebuild it if needed > ==> Will put log info to 'stdout' > ==> > ==> Do you want to run this program?[N/Yes] (note need to type Yes if > you do):Yes > ==> > ==> reiserfs_open: the reiserfs superblock cannot be found on /dev/md0. > ==> > ==> what the version of ReiserFS do you use[1-4] > ==> (1) 3.6.x > ==> (2) >=3.5.9 (introduced in the middle of 1999) (if you use > linux 2.2, choose > ==> this one) > ==> (3) < 3.5.9 converted to new format (don't choose if unsure) > ==> (4) < 3.5.9 (this is very old format, don't choose if unsure) > ==> (X) exit > ==> 1 > ==> > ==> Enter block size [4096]: > ==> 16384 blocksize cannot be larger than page size. > ==> rebuild_sb: wrong block size specified, only divisible by 1024 are > supported > ==> currently not clear message, within 512-8192 region. > ==> > ==> [EMAIL PROTECTED] > > So far as I know, 1024 * 16 = 16384. I'm currently running on a > Knoppix 3.9 CD, using the included reiserfsprogs package. It uses the > 2.6.11 linux kernel. My system doesn't have any stability issues that > should cause it to divide incorrectly :-). Since this appears to be > an interface error rather than an operation error, I don't think my > kernel modules are relevant, but a log of sorts listing all of the > steps I've taken to diagnose my problems since they started can be > found at http://forums.gentoo.org/viewtopic-t-371570.html. It > contains a lot of information about my current setup, but much of the > early text refers to attempts to check for hardware problems and to > fix a software raid problem. > If/when I can get past this error message, I hope I am correct in > assuming the the program shouldn't have any trouble actually > performing the superblock rebuild with a block size of 16384? you are right, it is not a problem for progs. however, recovery with the wrong blocksize will make more harm than good. if not sure about blocksize (or partition start), make a raw backup of the device (dd, dd_rescue) before rebuilding. then proceed with the wanted blocksize (512-8K, probably the default is the correct one) and rebuild the journal header if needed. > I've > been running this filesystem for two years with that block size, and > am not ready to give up the data on it just yet :-). > Thanks for any help with this problem, and also for the wonderul file > system :-). > Alphanos > > -- Thanks, Vitaly Fertman
Re: reiser4progs 1.0.5 configure script and libaal 1.0.5
On Monday 15 August 2005 18:11, Vanuxem Grégory wrote: > Le lundi 15 aoШt 2005 Ю 17:48 +0400, Vitaly Fertman a Иcrit : > > > > where have you installed libaal into? /usr/local? > > > > does you /etc/ld.so.conf have the path you instatlled libaal into? > > > > if not, add it and run /sbin/ldconfig. > > > > > > > > > > Yes but that doesn't work > > > > > > here is the output: > > > > > > checking for special C compiler options needed for large files... no > > > checking for _FILE_OFFSET_BITS value needed for large files... no > > > checking for _LARGE_FILES value needed for large files... no > > > configure: WARNING: Can't detect right _FILE_OFFSET_BITS. Will be forced > > > to 64bit. > > > checking for off_t... yes > > > checking size of off_t... 8 > > > checking for aal_device_open in -laal... yes > > > checking aal/libaal.h usability... yes > > > checking aal/libaal.h presence... yes > > > checking for aal/libaal.h... yes > > > checking for libaal version = 1.0.5... no > > > ellipse:/home/greg/temp/reiser4progs-1.0.5# > > > > so what do you see in config.log? > Sended. ok. > > which test program fails? > Don't know > > do you see a libaal.so in the wanted place? > Yes > > actually there is --with-libaal option for not standard > > places, but you are not supposed to use it if you install > > libaal by default. > > > > is it possible to get an access to your computer to test it? > > with root access ??? no, it is not necessary. > > > > > That works only in a chrooted 32bits environment > > > (I have a x86_64) > > > > what distro? > Debian AMD64 > > > > Cheers, > > Greg > -- Thanks, Vitaly Fertman
Re: reiser4progs 1.0.5 configure script and libaal 1.0.5
> > where have you installed libaal into? /usr/local? > > does you /etc/ld.so.conf have the path you instatlled libaal into? > > if not, add it and run /sbin/ldconfig. > > > > Yes but that doesn't work > > here is the output: > > checking for special C compiler options needed for large files... no > checking for _FILE_OFFSET_BITS value needed for large files... no > checking for _LARGE_FILES value needed for large files... no > configure: WARNING: Can't detect right _FILE_OFFSET_BITS. Will be forced > to 64bit. > checking for off_t... yes > checking size of off_t... 8 > checking for aal_device_open in -laal... yes > checking aal/libaal.h usability... yes > checking aal/libaal.h presence... yes > checking for aal/libaal.h... yes > checking for libaal version = 1.0.5... no > ellipse:/home/greg/temp/reiser4progs-1.0.5# so what do you see in config.log? which test program fails? do you see a libaal.so in the wanted place? actually there is --with-libaal option for not standard places, but you are not supposed to use it if you install libaal by default. is it possible to get an access to your computer to test it? > That works only in a chrooted 32bits environment > (I have a x86_64) what distro? -- Thanks, Vitaly Fertman
Re: reiser4progs 1.0.5 configure script and libaal 1.0.5
On Saturday 13 August 2005 20:26, Vanuxem Grégory wrote: > Le samedi 13 aoШt 2005 Ю 20:22 +0400, Vladimir V. Saveliev a Иcrit : > > Hello > > > > Vanuxem GrИgory wrote: > > > Hi, > > > > > > The lastest reiser4progs (1.0.5) can't find libaal > > > in configure script. > > > > > > More precisely it doesn't find libaal because of version problem > > > > > > > > > Any idea ? > > > > > Have you installed > > ftp://ftp.namesys.com/pub/reiser4progs/libaal-1.0.5.tar.gz? > > Yes, sure where have you installed libaal into? /usr/local? does you /etc/ld.so.conf have the path you instatlled libaal into? if not, add it and run /sbin/ldconfig. -- Thanks, Vitaly Fertman
Re: Strange problems/bugs with reiserfs and reiserfschk
t; vpf-10260: The file we are inserting the new item (432679 432828 0x2a001 > IND (1) > , len 132, location 3964 entry count 0, fsck need 1, format new) into > has no Sta > tData, insertion was skipped > (***snip***) > vpf-10260: The file we are inserting the new item (526132 526780 0x1 IND > (1), len 8, location 4088 entry count 0, fsck need 1, format new) into > has no StatData, insertion was skipped > vpf-10260: The file we are inserting the new item (557044 557073 0x1 IND > (1), len 4, location 4092 entry count 0, fsck need 3, format new) into > has no StatData, insertion was skipped > vpf-10260: The file we are inserting the new item (558483 558492 0x20001 > IND (1), len 96, location 4000 entry count 0, fsck need 1, format new) > into has no StatData, insertion was skipped > vpf-10260: The file we are inserting the new item (759159 759160 0x1 IND > (1), len 3208, location 888 entry count 0, fsck need 1, format new) into > has no StatData, insertion was skipped > left 32022, 500 /sec > > > -- Thanks, Vitaly Fertman
reiser4progs 1.0.5
Hi all, the reiser4progs & libaal 1.0.5 are releazed and available on ftp://ftp.namesys.com/pub/reiser4progs/ Against 1.0.4 the new releaze includes lots of fixes, handles the extended plugin table (with crypto compression fields) correctly. Crypto-compression plugins themselves are not ready yet. -- Thanks, Vitaly Fertman
Re: Strange problems/bugs with reiserfs and reiserfschk
portant 30% of these 400GB) I started a reiserfsck --rebuild-tree. > It worked quite good until about the end. There it seems to be frozen > and consumes 100% CPU. Here some data: > > reiserfsprogs-3.6.19, messages of reiserfsck: > > ** > .pass1: block 145817616, item 1, entry 0: The entry ".." of the [259961 > 259992 0x2 DIR (3)] is hashed with not set whereas proper hash is "r5" - > deleted > 100% left 0, 212 /sec > Flushing..finished > 268526 leaves read > 203192 inserted > - pointers in indirect items pointing to > metadata 1890 (zeroed) > 65334 not inserted > non-unique pointers in indirect items (zeroed) 28669 > ### Pass 2 ### > > Pass 2: > 0%20%40%..vpf-10260: The file we are inserting the new item > (2198390 2199894 0x381 DRCT (2), len 1088, location 3008 entry count > 65535, fsck need 0, format new) into has no StatData, insertion was skipped > vpf-10260: The file we are inserting the new item (2195955 2195990 0x1 > DRCT (2), len 792, location 3304 entry count 65535, fsck need 0, format > new) into has no StatData, insertion was skipped > (snip) > vpf-10260: The file we are inserting the new item (563378 563928 0x1 > DRCT (2), len 1384, location 2712 entry count 65535, fsck need 0, format > new) into has no StatData, insertion was skipped > vpf-10260: The file we are inserting the new item (563378 564627 0xa9 > DRCT (2), len 688, location 3408 entry count 65535, fsck need 0, format > new) into has no StatData, insertion was skipped > left 32269, 422 /sec > ** > > And that's the point where it's staying for hours now consuming 100% > CPU. I didn't try to abort and start again (yet) as it takes about 20 > hours to get so far (the device is big and not so fast) so I'm still > hoping it may finish by itself... there are some optimizations ready for the pass2. if fsck fails to recover the fs, gets out of disk space, etc, email me and I will send you the optimized reiserfsprogs version. > So, is it worth investigating and if, what other info I could provide? > If nobody is interested I will create a fresh FS on the drive and forget > about it. I have my important data so that would be OK. > > Keep doing the great job! > Konstantin > > -- Thanks, Vitaly Fertman
Re: newly created 8.5TB reiserfs fails fsck on amd64 and causes OOPS
Hello, On Tuesday 19 July 2005 15:47, Paul Slootman wrote: > This is on a dual-CPU opteron system, with 2 x 3ware 9500 12-channel > SATA controllers for a total of 8.5TB; I've configured a RAID5 over each > 3ware controller, and use linux md RAID0 over those two "devices". > There was an issue with linux md RAID0 for that size, but that's been > resolved (at least, the problem I had first :-) > > The device itself seems to work fine, as reiser4 works. I > wanted to compare to reiserfs 3.6, so I created a reiserfs, mounted it, > and tried to use it. Running bonnie++ on it caused an oops, apparently > in the reiserfs code: > > I rebooted (hard, as a shutdown didn't work...). After that, I tried a > mkfs followd by an fsck, which gives an error! Here's the console log: > > > satazilla:~# mkfs.reiserfs /dev/md13 > mkfs.reiserfs 3.6.19 (2003 www.namesys.com) > > Guessing about desired format.. Kernel 2.6.12.2.raid0fixreiser4 is running. > Format 3.6 with standard journal > Count of blocks on the device: 2148377056 ahh, indeed, this amount of blocks needs 65564 bitmap count, whereas there is only 16 bits field in the super block for the bitmap count. in other words, this limits the reiserfs size to: 65535 * BlockSize * 8 * Blocksize, for BlockSize == 4K it is 8T. the check for bitmap block count overflow seems to be missed in progs. hmm, and our faq about 16Tb is not correct also... > Number of blocks consumed by mkreiserfs formatting process: 8239 > Blocksize: 4096 > Hash function used to sort names: "r5" > Journal Size 8193 blocks (first block 18) > Journal Max transaction length 1024 > inode generation number: 0 > UUID: 10ae60ee-1abb-49d1-ae55-cf238626c0b5 > ATTENTION: YOU SHOULD REBOOT AFTER FDISK! > ALL DATA WILL BE LOST ON '/dev/md13'! > Continue (y/n):y > Initializing journal - 0%20%40%60%80%100% > Syncing..ok > > Tell your friends to use a kernel based on 2.4.18 or later, and especially > not a > kernel based on 2.4.9, when you use reiserFS. Have fun. > > ReiserFS is successfully created on /dev/md13. > satazilla:~# reiserfsck /dev/md13 > reiserfsck 3.6.19 (2003 www.namesys.com) > > Will read-only check consistency of the filesystem on /dev/md13 > 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 Jul 19 13:29:22 2005 > ### > Replaying journal.. > No transactions found > reiserfs_open_ondisk_bitmap: wrong either bitmaps number, > count of blocks or blocksize, run with --rebuild-sb to fix it > reiserfsck: Could not open bitmap > When I try running with --rebuild-sb it says: > > Reiserfs super block in block 16 on 0x90d of format 3.6 with standard journal > Count of blocks on the device: 2148377056 > Number of bitmaps: 28 > Blocksize: 4096 > Free blocks (count of blocks - used [journal, bitmaps, data, reserved] > blocks): 2148368817 > Root block: 8211 > Filesystem is clean > Tree height: 2 > Hash function used to sort names: "r5" > Objectid map size 2, max 972 > Journal parameters: > Device [0x0] > Magic [0x168ed58c] > Size 8193 blocks (including 1 for journal header) (first block 18) > Max transaction length 1024 blocks > Max batch size 900 blocks > Max commit age 30 > Blocks reserved by journal: 0 > Fs state field: 0x0: > sb_version: 2 > inode generation number: 0 > UUID: 10ae60ee-1abb-49d1-ae55-cf238626c0b5 > LABEL: > Set flags in SB: > ATTRIBUTES CLEAN > > Super block seems to be correct > > > > Something seems seriously wrong here. > I'm happy to run any tests or try any patches, this system is mine to play > with > until the end of the month. > > > Paul Slootman > > -- Thanks, Vitaly Fertman
Re: reiser4progs do not handle the reiser4 format changes
On Sunday 24 July 2005 03:44, Edward Shishkin wrote: > Edward Shishkin wrote: > > > David Masover wrote: > > > >> > >> > >> Ok, please explain what this actually means for users. > >> > >> How will an FS made by the current reiser4progs be different than > >> that made by the new (patched) ones that will be coming out? Is the > >> new way better? If so, how can one take an existing FS and > >> convert/update/tweak it to the new way? > >> > > > > This is a common scenario: > > > > Each disk reiser4 is supposed to be supported by all kernel/reiser4. > > > I was wrong here: the only last version of kernel/reiser4 is able > to support _all_ disk file systems. Old kernels will refuse to mount > file systems of new versions with the warning about wrong plugin set > of root inode. > > Edward. > > > > > Both kernel and reiser4progs have a plugin table which should be > > upgraded in sync. > > For each point A of upgrading the plugin table all reiser4progs of > > versions < A > > become invalid for disk reiser4 being once mounted in the > > kernel/reiser4 of version >= A. > > > > Is it okay? > > Perhaps introducing a special sub-versions of reiser4/reiser4progs for > > upgrading > > the plugin table will improve the situation.. the reiser4progs obtained from ftp.namesys.com/pub/reiser4progs/reiser4progs-1.0.4-1.tar.gz contain the fix to handle the extended plugin table correctly. -- Thanks, Vitaly Fertman
Re: reiser4 plugins
On Friday 24 June 2005 03:57, Hans Reiser wrote: > One, you were using V3 not V4. > > Two, this bug you mention is probably not an fs bug. rm first creates a > list of names, and then removes them. shell creates a list of names, rm simply handles the given set of names and tries to remove a file twice if specified twice. the problem could be in the shell, or what is more likely in patterns that overlap each other, like in the example of 'rm *fu fi*'. we should probably investigate a reproducable example. > [EMAIL PROTECTED]:~/scratch> touch fufu > [EMAIL PROTECTED]:~/scratch> touch fifu > [EMAIL PROTECTED]:~/scratch> rm *fu fi* > rm: cannot remove `fifu': No such file or directory > > Your file either somehow got removed before rm got to it, or rm somehow > got to it twice. Vitaly, can you look at the error handling by rm and > see if it can get to things twice when it hits an error or if you can once per every given name. > otherwise figure this out? If I remember right, I have hit this myself > for non-reiserfs filesystems, and I never investigated it. > > Michael Dreher wrote: > > >>>>Not everyone will want > >>>>to reformat at once, but as the reiser4 code matures and proves itself > >>>>(even more than it already has), > >>>> > >>>> > >>>I for one have seen mainly people with wild claims that it will make > >>>their machines much faster, and coming back later asking how they can > >>>recover their thrashed partitions... > >>> > >>> > >>Then please show us some Links/Message-IDs to such postings. > >>I'd like to read them. > >> > >> > > > >Here you are > > > >The following happened to me with reiserfs as it was shipped with > >suse 9.1: > > > >-- > >[EMAIL PROTECTED]:~/mytex/konstanz/wohnung> ls > >auto makler2.aux makler2.log makler2.tex makler.aux makler.log > >swk.eps unilogo.eps > >briefkpf.tex makler2.dvi makler2.ps makler3.tex makler.dvi makler.tex > >unikopf.tex > >[EMAIL PROTECTED]:~/mytex/konstanz/wohnung> rm *.aux *.log > >rm: cannot remove `makler2.log': No such file or directory > >[EMAIL PROTECTED]:~/mytex/konstanz/wohnung> ls > >auto briefkpf.tex makler2.dvi makler2.ps makler2.tex makler3.tex > >makler.dvi makler.tex swk.eps unikopf.tex unilogo.eps > >[EMAIL PROTECTED]:~/mytex/konstanz/wohnung> uname -a > >Linux euler03 2.6.5-7.108-smp #1 SMP Wed Aug 25 13:34:40 UTC 2004 i686 i686 > >i386 GNU/Linux > >[EMAIL PROTECTED]:~/mytex/konstanz/wohnung> date > >Tue Sep 21 13:15:45 CEST 2004 > >-- > > > >Note the line "rm: cannot remove `makler2.log': No such file or directory" > > > >There was no data loss, but such a bug should not happen. > >I never had similar experiences with ext3. > > > >Unfortunately, I cannot reproduce this behavior. > > > > > > > >> Powerloss, unpluging the Disk while writing, full filesystem, > >> heavy use : No problems with reiser4.. It *is* stable. > >> > >> > > > >My impression: reiser3 is not 100% stable, but quite stable, > >written by someone who asks for "review by benchmark". > > > >Michael > > > > > > > > > > > -- Thanks, Vitaly Fertman
Re: reiser4 plugins
On Tuesday 28 June 2005 01:07, David Masover wrote: > Vitaly Fertman wrote: > > On Friday 24 June 2005 23:46, Hans Reiser wrote: > > > >>David Masover wrote: > >> > >> > >> > >>> > >>>I was able to recover from bad blocks, though of course no Reiser that I > >>>know of has had bad block relocation built in... > >> > >>there was a patch somewhere. Vitaly, please comment. > > > > > > http://www.namesys.com/bad-block-handling.html describes > > how reiserfs handles bad blocks. > > Anything like this for v4? in todo for v4, not implemented yet. -- Thanks, Vitaly Fertman
Re: reiser4 plugins
On Sunday 26 June 2005 23:05, Hans Reiser wrote: > Reuben Farrelly wrote: > > > Hi Hans, > > > > On 25/06/2005 12:38 a.m., Hans Reiser wrote: > > > >> fsck is better in V4 than it is in V3. Users should move from V3 to V4, > >> as V3 is obsolete. I agree on that Ted. > > > > > > Perhaps before moving to V4, reiser4progs-1.04 (the most recent I > > think) could be made to compile with gcc4/fedora core 4 system, and > > some of the warnings cleaned up. There are a fair lot of them - all > > the same warnings as below but in a heap of different files. > > > I will ask Vitaly to look into this. None of us at Namesys use fedora. > > Vitaly? yes, I will investigate the problem. -- Thanks, Vitaly Fertman
Re: reiser4 plugins
On Friday 24 June 2005 23:46, Hans Reiser wrote: > David Masover wrote: > > > > > > > > I was able to recover from bad blocks, though of course no Reiser that I > > know of has had bad block relocation built in... > > there was a patch somewhere. Vitaly, please comment. http://www.namesys.com/bad-block-handling.html describes how reiserfs handles bad blocks. -- Thanks, Vitaly Fertman
Re: hard hang with reiser4-for-2.6.11-5 and VMware Workstation 5.0
On Saturday 18 June 2005 14:29, Markus TЖrnqvist wrote: > On Fri, Jun 17, 2005 at 09:30:40PM +0400, E.Gryaznova wrote: > > >Reiser4 format was changed in reiser4-5 patch for 2.6.11, reiser4progs > >for this format are not ready yet. > > So, erhm, can we expect a smooth transition here? yes, the patch is being tested. > Update the tools, do something light and off we go or will we > need to mkfs? > > Spatsibo! > -- Thanks, Vitaly Fertman
Re: Corrupt reiser3 fs
On Sunday 12 June 2005 02:42, Paul Gear wrote: > Hi folks, > > After filling my reiserfs with backups, i ended up with a corrupt > filesystem. I'm running Debian 3.1 (sarge), kernel 2.6.8-2-k7, and > reiserfsprogs 3.6.19-1. > > I don't care about this filesystem and will just recreate it, but i > thought i'd offer folks the opportunity to debug before i trash it. > > Here's my fsck output with all the noise cut out: > > -8< > > enoch:/tmp # fsck.reiserfs --rebuild-tree /dev/hdc1 > ... > 111392 directory entries were hashed with "r5" hash. > "r5" hash is selected > Flushing..finished > Read blocks (but not data blocks) 19333032 > Leaves among those 32365 > - corrected leaves 35 > - leaves all contents of which could not be > saved and deleted 5 > pointers in indirect items to wrong area 25647 (zeroed) > Objectids found 104921 > > Pass 1 (will try to insert 32360 leaves): > ### Pass 1 ### > Looking for allocable blocks .. finished > 0%20%40%60%... left 8239, > 234 /sec > The problem has occurred looks like a hardware problem (perhaps > memory). Send us the bug report only if the second run dies at > the same place with the same block number. > > build_the_tree: Nothing but leaves are expected. Block 10905053 - unknown does it stop every time on the block 10905053 ? > > There is no problem with memory (my other two hard disks and all of my > desktop programs are working fine), or, to my knowledge, the hard disk > or cable (since i can do a full dd of the hard disk to /dev/null). > > Anyone interested in taking a look at it, or should i just write it off > as stray gamma rays from Saturn and trash it? :-) > -- Thanks, Vitaly Fertman
Re: ReiserFS.3 root block problem
On Thursday 09 June 2005 13:51, [EMAIL PROTECTED] wrote: > Hi, im newbie w/ mailinglists, this is my 1st, so sorry for mistakes.. > > I got problem with my reiserfs partition version 3.x.1b. I have 4x200gb > disks. I put it to LVM so i got 800gb LVM.. Then i mkreiserfs system there.. > All works ok about 2years, but week ago i got badblocks problem w/ one disk. > So i try to check partition, get list of badblocks via debugreiserfs and then > fix it. But things goes bad and now im not able to mount this partition. > > debugreiserfs shows me Root block: 0 and I think this is bad. Is there any > way how to fix filesystem? Im crazy about it, because all data are there, > only thing to do is to fix filesystem and mount it :-/ > > (linux, 2.4.20(debian), reiserfs 3.x.1b, but i try 3.6.19 also, but still the > same) what does reiserfsck say? we handle hardware problems under www.namesys.com/support.html terms. -- Thanks, Vitaly Fertman
Re: My reiserfs module crash...
On Thursday 09 June 2005 12:01, Greg Burri wrote: > Vitaly wrote: > > >>Hi ! > >>I have done "debugreiserfs -p" to collect metadata .. .I take me about > >>15 hours but its ok. > >>I have put the file here : > >>http://www.euphorik.ch/boardel/debugreiserfs_metadata.bz2 (23Mo) > >> > >> > > > >unfortunately I have failed to unpack metadata, they got corrupted > >somehow, but I see at least that fs is not consistent and you need > >to run > > reiserfsck --rebuild-tree -l logfile > >to fix it. > > > >there is also a problem with reiserfs module crash on mounting > >such a partition, we are working on the fix. > > > > > > > >>I wish that someone can help me, I don't want to loose all my data :'( > >> > >>bye ! > >>Thanks by advance > >> > >>Greg Burri > >> > >> > > > > > > > > > > > Re Hi ! > I have try this command for three times but It doesn't work. > #>reiserfsck --rebuild-tree -l logfile /dev/sda1 > > When I try to mount my partition after the reiserfsck the same problem > occure. > I have put the logs here with a screen dump for the third try : is the screen dump the same for all 3 times? > http://www.euphorik.ch/boardel/reiserfsck_rebuild_log_1.txt > http://www.euphorik.ch/boardel/reiserfsck_rebuild_log_2.txt > http://www.euphorik.ch/boardel/reiserfsck_rebuild_log_3.txt > http://www.euphorik.ch/boardel/reiserfsck_screendump_3.txt looks like a hardware problem, problably memory. > I think, maybe I'll format my partition, I'm a bit desperate :/ > > bye ! > > Greg Burri > > > > -- Thanks, Vitaly Fertman
Re: reiser4 panicked cowardly: assertion failed: hint->blk < reiser4_block_count(super)
On Tuesday 07 June 2005 15:01, Adrian Ulrich wrote: > Hi Vitaly, > > > there was a format change to work with encryption plugin in > > -5 reiser4 patch. progs do not have its support yet. grub works > > through the progs code so its the same problem, mkisofs is not > > relevant here. > > I don't think thats the problem: I am about the particular fsck message that appeares when you use -5 reiser4 patch: > > FSCK: Node (411219), item (0), [29:1(SD):0:2a:0]: does not look > > like a valid SD plugin set extention: wrong pset member count detected > > (12). > It looks like a remount bug: > See <[EMAIL PROTECTED]> (my other mail) >
Re: reiser4 panicked cowardly: assertion failed: hint->blk < reiser4_block_count(super)
On Monday 06 June 2005 22:39, Adrian Ulrich wrote: > I upgraded to Linux 2.6.11.11 using the -5 reiser4 patch. > > > It fixed it.. somewhat.. it's still funky: > > > * mkisofs doesn't crash with the new kernel, yeah! > * after running mkisofs, grub can't read the filesystem anymore.. >The filesystem got corrupted. (It was ok before i booted >into 2.6.11.11 and ran mkisofs !) > > So i bootet my rescue-system > (Same kernel, reiser4progs 1.0.4. It's on /dev/md3) > > Running fsck: > > [EMAIL PROTECTED]:~# fsck.reiser4 /dev/md1 > *** > This is an EXPERIMENTAL version of fsck.reiser4. Read README first. > *** > > Fscking the /dev/md1 block device. > Will check the consistency of the Reiser4 SuperBlock. > > Will check the consistency of the Reiser4 FileSystem. > > Continue? > (Yes/No): Yes > * fsck.reiser4 started at Mon Jun 6 20:07:51 2005 > Reiser4 fs was detected on /dev/md1. > Master super block (16): > magic: ReIsEr4 > blksize:4096 > format: 0x0 (format40) > uuid: c3fc85d3-be0d-4d71-9413-376cefcdf8fd > label: > > Format super block (17): > plugin: format40 > description:Disk-format for reiser4. > magic: ReIsEr40FoRmAt > flushes:0 > mkfs id:0x5bedb66f > blocks: 9765488 > free blocks:2035573 > root block: 4270052 > tail policy:0x2 (smart) > next oid: 0x62d63 > file count: 180460 > tree height:4 > key policy: LARGE > > > CHECKING STORAGE TREE > FSCK: Node (411219), item (0), [29:1(SD):0:2a:0]: does not look like a valid > SD plugin set extention: wrong pset member count detected (12). > FSCK: Node (411219), item (0), [29:1(SD):0:2a:0]: does not look like a valid > stat data. > FSCK: Node (411219), item (0), [29:1(SD):0:2a:0]: broken item found. > FSCK: Node (411219): the node is broken. Pointed from the node (411211), item > (0), unit (0). The whole subtree is skipped. there was a format change to work with encryption plugin in -5 reiser4 patch. progs do not have its support yet. grub works through the progs code so its the same problem, mkisofs is not relevant here. -- Thanks, Vitaly Fertman
Re: reiser4 panicked cowardly: assertion failed: hint->blk < reiser4_block_count(super)
On Sunday 05 June 2005 18:50, Adrian Ulrich wrote: > Hi, > > Well, i managed to crash reiser4 ;-) > > I created an iso-image on my reiser4 filesystem (it's my rootfs) > using mkisofs. mkisofs aborted because the filesystem was full. > After freeing up some space, i ran mkisofs again and: *bam* > > fsck.reiser4 told me to run '--rebuild-sb' but looks like > it didn't help: > The System still crashes while creating the ISO > (Should be 4.1 GiB, but crashes at ~ 3.7 GiB..) what does 'fsck.reiser4 --check' say now running on this fs? that no corruption found? > # fsck.reiser4 --version > fsck.reiser4 1.0.4 > Copyright (C) 2001, 2002, 2003, 2004 by Hans Reiser, licensing governed > by reiser4progs/COPYING. > > # uname -a > Linux fuzzy 2.6.11.10 #1 SMP Sat May 21 13:17:21 CEST 2005 i686 unknown > unknown GNU/Linux > > * I attached the Syslog output > * I rand 'debugfs.reiserf -P $device' and can > provide the output to namesys if they need it > (9.3 MiB) > -- Thanks, Vitaly Fertman
Re: Reiserfsck 1300Gig failed with following error
On Wednesday 01 June 2005 16:28, Matthias Barremaecker wrote: > >>How do you sugest I swap a hd in a LVM raid with already data on it ? > > > > > > dd_rescue hd to a relable one & change lvm according to the change. > > if you need our assistance please use our www.namesys.com/support.html > > service. > > I start to find that answer super funny.:)) I'm willing to pay if you > fix my problem. Maybe you can start saying if the problem is fixable. > > Situation : > > LVM with reiserfs > > 2 onboard IDE controllers => 8 disks > > I can't connect another disk fysicly perform dd_rescue'ing on another computer. or alternatively you can pull out a working disk out, put a new one, dd_rescue the broken one to a new one, put the new one instead of the broken one and put the pulled out disk back to its own place. > system boots from a scsi disk, that has nothing to do with the LVM > except booting and mounting it . > > What should I do before I pay you to work out a solution. > > thanx. > > kind regardes, > > > Matthias. > > > -- Thanks, Vitaly Fertman
Re: reiser4 on large block devices
On Tuesday 31 May 2005 22:42, Aaron Porter wrote:
>
> I'm trying to create a reiser4 filesystem on a ~4tb block device,
> but I'm getting the error "Fatal: The partition size is too big." The FAQ
> seems to list a max filesystem size of 16tb. Am I missing something?
>
> diablo:~# mkreiser4 /dev/sda3
> mkreiser4 1.0.4
> Copyright (C) 2001, 2002, 2003, 2004 by Hans Reiser, licensing governed by
> reiser4progs/COPYING.
>
> Block size 4096 will be used.
> Linux 2.6.11.8 is detected.
> Uuid f22c4f94-4fcd-4655-b4e0-6665048db8ce will be used.
> Fatal: The partition size is too big.
> Reiser4 is going to be created on /dev/sda3.
> (Yes/No): no
> diablo:~#
would you try this patch for libaal-1.0.4?
--
Thanks,
Vitaly Fertman
# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
# 2005/03/21 13:15:23+03:00 [EMAIL PROTECTED]
# use BLKBLKGETSIZE & BLKGETSIZE6464 defines
#
# file.c:
# do not limit file size by 2^41 bytes
#
# configure.in:
# check for large files correctly
#
# src/file.c
# 2005/03/21 13:14:02+03:00 [EMAIL PROTECTED] +3 -4
#
# src/file.c
# 2005/03/21 12:40:49+03:00 [EMAIL PROTECTED] +3 -14
# do not limit file size by 2^41 bytes
#
# configure.in
# 2005/03/21 12:40:29+03:00 [EMAIL PROTECTED] +1 -1
# check for large files correctly
#
diff -Nru a/configure.in b/configure.in
--- a/configure.in 2005-06-01 15:50:06 +04:00
+++ b/configure.in 2005-06-01 15:50:06 +04:00
@@ -136,7 +136,7 @@
GENERIC_CFLAGS="$GENERIC_CFLAGS -D_REENTRANT"
AC_SYS_LARGEFILE
-if test -z "${ac_cv_sys_file_offset_bits}"; then
+if test x${ac_cv_sys_file_offset_bits} = xno; then
AC_MSG_WARN(Can't detect right _FILE_OFFSET_BITS. Will be forced to 64bit.)
ac_cv_sys_file_offset_bits=64
fi
diff -Nru a/src/file.c b/src/file.c
--- a/src/file.c 2005-06-01 15:50:06 +04:00
+++ b/src/file.c 2005-06-01 15:50:06 +04:00
@@ -18,6 +18,9 @@
#include
#include
+/* BLKGETSIZE & BLKGETSIZE64 defines: */
+#include
+
#include
/* Function for saving last error message into device assosiated buffer */
@@ -193,10 +196,6 @@
return !aal_strncmp(file1, file2, aal_strlen(file1));
}
-#if defined(__linux__) && defined(_IOR) && !defined(BLKGETSIZE64)
-# define BLKGETSIZE64 _IOR(0x12, 114, uint64_t)
-#endif
-
/* Handler for "len" operation for use with file device. See bellow for
understanding where it is used. */
static count_t file_len(
@@ -209,18 +208,8 @@
return INVAL_BLK;
#ifdef BLKGETSIZE64
- if ((int)ioctl(*((int *)device->entity), BLKGETSIZE64, &size) >= (int)0) {
- uint32_t block_count;
-
- size = (size / 4096) * 4096 / device->blksize;
- block_count = size;
-
- if ((uint64_t)block_count != size) {
- aal_fatal("The partition size is too big.");
- return INVAL_BLK;
- }
-
- return (count_t)block_count;
+ if (ioctl(*((int *)device->entity), BLKGETSIZE64, &size) >= 0) {
+ return size / device->blksize;
}
#endif
@@ -231,8 +220,7 @@
if (ioctl(*((int *)device->entity), BLKGETSIZE, &l_size) >= 0) {
size = l_size;
- return (count_t)((size * 512 / 4096) * 4096 /
-device->blksize);
+ return size * 512 / device->blksize;
}
}
Re: Reiserfsck 1300Gig failed with following error
On Wednesday 01 June 2005 14:57, Matthias Barremaecker wrote: > Hi, > > > the key (which is in the tree already and supposed to be correct) is > > completely corrupted, no one key component is correct. data could be > > corrupted in the memory or on read/write -- bad cable, controller, > > dying harddrive, etc. > > > > > >>Anyone any suggestions ? > > > > > > running fsck with the list of bad blocks is useful when you have the > > known fixed number of bad blocks, you know that the number will not > > change soon, in other words other blocks are relable. > > > > first of all you even have not complete badblocks run, so you cannot > > be sure you know the full bad block list. > > > > and the second, if your hardware is dying you need to fix it before > > running fsck on it. > > How do you sugest I swap a hd in a LVM raid with already data on it ? dd_rescue hd to a relable one & change lvm according to the change. if you need our assistance please use our www.namesys.com/support.html service. -- Thanks, Vitaly Fertman
Re: Reiserfsck 1300Gig failed with following error
On Wednesday 01 June 2005 10:47, Matthias Barremaecker wrote: > Hi, > > using reiserfsprogs-3.6.19 > > Here is the error and messages : ... > > > 2 directory entries were hashed with not set hash. > 731305 directory entries were hashed with "r5" hash. > "r5" hash is selected > Flushing..finished > Read blocks (but not data blocks) 313507947 > Leaves among those 439626 > - corrected leaves 46 > - leaves all contents of which could not be > saved and deleted 56 > pointers in indirect items to wrong area 3997 (zeroed) > Objectids found 731997 > > Pass 1 (will try to insert 439570 leaves): > ### Pass 1 ### > Looking for allocable blocks .. finished > 0%20%40%pass1.c 212 balance_condition_2_fails > balance_condition_2_fails: block 1288402, pointer 168: The left > delimiting key [1412453424 1412453424 0x10001000 ??? (15)] of the block > (170046457) is wrong,the item cannot be found the key (which is in the tree already and supposed to be correct) is completely corrupted, no one key component is correct. data could be corrupted in the memory or on read/write -- bad cable, controller, dying harddrive, etc. > > Anyone any suggestions ? running fsck with the list of bad blocks is useful when you have the known fixed number of bad blocks, you know that the number will not change soon, in other words other blocks are relable. first of all you even have not complete badblocks run, so you cannot be sure you know the full bad block list. and the second, if your hardware is dying you need to fix it before running fsck on it. -- Thanks, Vitaly Fertman
Re: Fwd: Bug#309512: reiserfsprogs: Typo in reiserfstune manpage
On Sunday 29 May 2005 18:38, Domenico Andreoli wrote: > cheers > domenico > > > - Forwarded message from Dennis Brakhane <[EMAIL PROTECTED]> - > > Date: Tue, 17 May 2005 19:46:56 +0200 > From: Dennis Brakhane <[EMAIL PROTECTED]> > Subject: Bug#309512: reiserfsprogs: Typo in reiserfstune manpage > > Package: reiserfsprogs > Version: 1:3.6.19-1 > Severity: minor > > The manpage describes reiserfstune as a "tunning" tool. Thanks, fixed. -- Vitaly Fertman
Re: Reiserfsck fails. Out of disk space on pass 2
On Wednesday 11 May 2005 14:02, [EMAIL PROTECTED] wrote: > Hello guys! > I wonder if you can help me. > A couple of days ago my system failed: a big-big-BIG kernel dump on the > screen and system hang, so I rebooted. The first time my debian couldn't > start x.org because there was not enough free space "Uh?, Okay, let's > check the partition" So I rebooted again and started a second installation > I have in a different partition for these situations. > I logged in and started normally, checked my original root partition (on > /dev/hda3) and at pass 2 it aborted > > Not enough allocable blocks, checking bitmap...there are 0 allocable > blocks , btw > > out of disk space how did you run reiserfsck? what version of reiserfsprogs do you use? you should use the latest, it is 3.6.19 now. > After that it is impossible to recover the partition. Obviously I cannot > mount it either. I have repeated it several times and always the same > fail. > I have tried giving this partition more space but no success. Gparted > doesn't work and reports 2.00 Tb of data in a 19 Gb partition! > Any idea of what am I doing wrong (because I suppose that this problem can > be solved but I don't know how) > I have googled but no similar incident has been reported. > > Thank in advance > > > M. A. Herrero. > > > -- Thanks, Vitaly Fertman
Re: Reiser4 support on parted ...
On Friday 06 May 2005 13:31, Dr. Giovanni A. Orlando wrote:
> Hans Reiser wrote:
>
> >I think someone is going to pay us to write the online repacker in the
> >very near future, though I can't say their name.
> >
> >Giovanni, if by parted support you mean that you are going to write a
> >resizer (and now that I take a moment to remember what parted does it
> >seems certain you do mean that), I wish you would not. We are so
> >amazing far in debt right now
> >
> >
> Hi,
>
> It is important to fix some points to clarify.
>
> At first, "parted" is a binary that interact with the "libparted"
> library to run
> some features about partitions, like:
>* mkfs
>* fsck
>* cp
>* mv
>* resize
>* and others.
>
> Actually, parted have zero support for Reiser4.
>
> Why we need Reiser4 support inside parted?
>
> We need that parted support Reiser4, because our installer actualy a
> hacked version of RedHat anaconda
> uses pyparted that need parted to create the partitions on the FS on
> a new installation.
> (Therefore also RH people and Linux distro that uses anaconda, like
> YellowDog will benefit for this code).
>
> Therefore, we don't need to resize Reiser4 partitions actually.
>
> The necessary code is not necessarely complicated, because libraries
> are well written.
> However, I need to understant how Reiser4 do jobs like fsck and mkfs
> and this code
they are wrappers to libreiser4 & librepair. also have a look at
reiser4progs/demos/busy (it is able to create file on reiser4,
copy them to/from, rm, stat, truncate, etc) which is the wrapper
to libreiser4 too.
> cannot be a simple or equivalent (system("mkfs.reiser4")).
>
> It is necessary to use the parted API to do that.
>
> FTOSX 2004 includes "reiser4" packages, including "libaal", from Sep
> 2004.
> (Check ftp://ftp.futuretg.com/pub/FTOSX/FTOSX_Desktop_2004/i386/SRPMS)
>
> I create some directories, one for parted 1.6.15 (my hacked version)
> and another for (1.6.22), latest one.
>
> People that want to know more about the internal of this code, can
> browse:
>
> ftp://ftp.futuretg.com/pub/Projects/parted+Reiser4/Actual_without_support/parted-1.6.15/doc/TUTORIAL
>
> I need to update around 111 chapters in six courses, and therefore I
> will dedicate only 1/2 hours per day to move on
> on this matter.
>
> Thanks,
> Giovanni.
>
>
>
> --
>
>
> --
> --
>
> Check FT Websites ... http://www.futuretg.com - ftp://ftp.futuretg.com
> http://www.FTLinuxCourse.com
> http://www.FTLinuxCourse.com/Certification
> http://www.RPMParadaise.org
> http://www.YourPersonalOperatingSystem.com
>
> Mobile: +39 393 665 4239
> Lancelot is back!
--
Thanks,
Vitaly Fertman
Re: My reiserfs module crash...
On Thursday 05 May 2005 03:03, Greg Burri wrote: > Hi everybody ! > I have a big trouble with my reiserfs partition :/, I wish that someone > can help me. so I'll expose my problem. > (I'm don't know very well english so I'll to make the better I can, > sorry in advance) > > So. I use reiserfs 3.6.19 under a Debian sarge Linux distribution, I use > the kernel 2.6.11 (but the bug appeared with a 2.6.8 too). > When I try to mount my partition the reiserfs module crash like that : > > #> mount -t reiserfs /dev/sda1 /var/data/ > ReiserFS: sda1: found reiserfs format "3.6" with standard journal > ReiserFS: sda1: using ordered data mode > ReiserFS: sda1: journal params: device sda1, size 8192, journal first > block 18, max trans len 1024, max batch 900, max commit age 30, max > trans age 30 > ReiserFS: sda1: checking transaction log (sda1) > ReiserFS: warning: is_tree_node: node level 0 does not match to the > expected one 65534 > ReiserFS: sda1: warning: vs-5150: search_by_key: invalid format found in > block 0. Fsck? > ReiserFS: sda1: warning: vs-13070: reiserfs_read_locked_inode: i/o > failure occurred trying to find stat data of [1 2 0x0 SD] > ReiserFS: sda1: Using r5 hash to sort names > [ cut here ] > kernel BUG at fs/reiserfs/journal.c:2858! > invalid operand: [#1] > Modules linked in: reiserfs ipv6 evdev pcspkr parport_pc parport 8139cp > i2c_viapro i2c_core pci_hotplug via_agp uhci_hcd usbcore 8139too mii > agpgart sd_mod capability commoncap hpt374 scsi_mod psmouse ide_cd cdrom > genrtc ext3 jbd mbcache ide_disk ide_generic via82cxxx trm290 triflex > slc90e66 sis5513 siimage serverworks sc1200 rz1000 piix pdc202xx_old > opti621 ns87415 hpt366 hpt34x generic cy82c693 cs5530 cs5520 cmd64x > atiixp amd74xx alim15x3 aec62xx pdc202xx_new unix fbcon font bitblit > vesafb cfbcopyarea cfbimgblt cfbfillrect ide_core > CPU:0 > EIP:0060:[]Tainted: PF VLI > EFLAGS: 00010246 (2.6.11-1-686) > EIP is at journal_mark_dirty+0x216/0x270 [reiserfs] > eax: ebx: e480e600 ecx: 0002 edx: c174be34 > esi: e480e600 edi: e8a84000 ebp: e47cb730 esp: c174bdb0 > ds: 007b es: 007b ss: 0068 > Process mount (pid: 3075, threadinfo=c174a000 task=c17dd0a0) > Stack: e480e600 e3670db0 c174a000 c174be34 e480e600 c174be10 e8b2283e > c174be34 >0002 e7f18120 e480e600 c174be34 0001 e8b11bc6 > c174be34 >e480e600 e47cb730 e8b04ee0 c174be10 c174be20 e43ea000 > > Call Trace: > [] journal_begin+0x6e/0x100 [reiserfs] > [] reiserfs_fill_super+0x576/0x770 [reiserfs] > [] reiserfs_init_locked_inode+0x0/0x20 [reiserfs] > [] snprintf+0x27/0x30 > [] sb_set_blocksize+0x2e/0x60 > [] get_sb_bdev+0x100/0x150 > [] alloc_vfsmnt+0x90/0xd0 > [] get_super_block+0x30/0x34 [reiserfs] > [] reiserfs_fill_super+0x0/0x770 [reiserfs] > [] do_kern_mount+0xa0/0x170 > [] do_new_mount+0x77/0xc0 > [] do_mount+0x174/0x1c0 > [] copy_mount_options+0x63/0xc0 > [] sys_mount+0x9a/0xe0 > [] syscall_call+0x7/0xb > Code: 83 47 2c 12 8b 42 08 e9 31 ff ff ff 8b 47 30 bd 00 b0 b2 e8 89 6c > 24 04 89 1c 24 89 44 24 08 e8 51 0a ff ff ba 01 00 00 00 eb bd <0f> 0b > 2a 0b 35 c4 b2 e8 e9 0a fe ff ff 89 54 24 0c 8b 54 24 3c would you pack the metadata with debugreiserfs -p /dev/sda1 | bzip2 -c > sda1-meta.bz2 and provide them for downloading. > (hpt374 is the driver for my sata-card) > My partition was in good health but a day I don't know why I had this > message when I was mounting /dev/sda1 ... > I already try reiserfsck but without success :'( I don't know what can I > do to repair that. > > Please help me, > Thx > > Greg Burri > > -- Thanks, Vitaly Fertman
Re: grub reiser4 won't compile
On Friday 29 April 2005 13:11, Chris Wakefield wrote: > Hi Vitaly. > > Thanks for your reply. > > I tried every reasonable combo: > apt-get source grub ... patched it with LATEST_PATCH ...that wouldn't compile > with or without the patch, > grub-0.95, > grub-0.96, if the grub-0.96 without reiser4 patch does not want to be configured, you should probably ask the grub guys about it: http://www.gnu.org/software/grub/grub-legacy-bugs.en.html > all the same result. > I wasn't sure what to do with "LATEST_GRUB", it seemed to be a binary for > some > reason. this is the rebuilt grub package with the applied reiser4 patch, it points to ftp.namesys.com/pub/reiser4progs/grub/grub-0.96-reiser4-20040130.tar.gz > I'm stumped. > > Thanks, > Chris W. > > On April 28, 2005 05:06 am, Vitaly Fertman wrote: > > On Thursday 28 April 2005 09:26, Chris Wakefield wrote: > > > Greetings all. > > > > > > I'm attempting to setup Reiser4 on a partition and I've got as far as > > > trying to compiling grub and I've run into a wall. > > > > > > It's a Reiser4 patched grub source from: > > > ftp://ftp.namesys.com/pub/reiser4progs/grub/LATEST_PATCH > > > > so is it reiser4 patched grub from LATEST_GRUB or > > the reiser4 grub patch from LATEST_PATCH? > > > > > anyways, I run configure and I get: > > > > > > "checking build system type... x86_64-unknown-linux-gnu > > > checking host system type... x86_64-unknown-linux-gnu... > > > > > > . > > > > > > "checking for C compiler default output file name... configure: > > > error: C compiler cannot create executables". > > > > > > config log error is: > > > ..."configure:2416: $? = 1 > > > configure: failed program was: | /* confdefs.h. */" .. > > > > > > This is happening only with reiser4 grub, as I'm able to compile kernels > > > and who knows what else .. it's just this source only. > > > Do I require a different source or do I have to compile reiser4 grub in a > > > 32 bit chroot environment? > > > > what does the plain grub-0.96 without reiser4 patch say? > > -- Thanks, Vitaly Fertman
Re: grub reiser4 won't compile
On Thursday 28 April 2005 09:26, Chris Wakefield wrote: > Greetings all. > > I'm attempting to setup Reiser4 on a partition and I've got as far as trying > to compiling grub and I've run into a wall. > > It's a Reiser4 patched grub source from: > ftp://ftp.namesys.com/pub/reiser4progs/grub/LATEST_PATCH so is it reiser4 patched grub from LATEST_GRUB or the reiser4 grub patch from LATEST_PATCH? > anyways, I run configure and I get: > > "checking build system type... x86_64-unknown-linux-gnu > checking host system type... x86_64-unknown-linux-gnu... > > . > > "checking for C compiler default output file name... configure: > error: > C compiler cannot create executables". > > config log error is: > ..."configure:2416: $? = 1 > configure: failed program was: | /* confdefs.h. */" .. > > This is happening only with reiser4 grub, as I'm able to compile kernels and > who knows what else .. it's just this source only. > Do I require a different source or do I have to compile reiser4 grub in a 32 > bit chroot environment? what does the plain grub-0.96 without reiser4 patch say? -- Thanks, Vitaly Fertman
Re: how manage this? (was: Bug#304342: /sbin/mkreiserfs: created a filesystem with mkreiserfs -b 1024 ...)
On Wednesday 27 April 2005 18:48, Domenico Andreoli wrote: > hi, > > which advice i can give to those users finding these absurd and > obviously buggy behaviours? thanks. > > cheers > domenico > > - Forwarded message from Miernik <[EMAIL PROTECTED]> - > > Date: Tue, 12 Apr 2005 16:26:33 +0200 > From: Miernik <[EMAIL PROTECTED]> > Subject: Bug#304342: /sbin/mkreiserfs: created a filesystem with > mkreiserfs -b 1024 and it hangs anything trying to write to it > > Package: reiserfsprogs > Version: 1:3.6.19-1 > Severity: normal > File: /sbin/mkreiserfs > > I created a partition made of 2618595 sectors (~1.3 GB) /dev/hda6 and > created a filesystem on it with > > mkreiserfs -b 1024 -l /var/cache/wwwoffle /dev/hda6 > > Anything trying to write on the filesystem (tried mc and touch) hangs > completely, shows about 60% to 65% CPU usage in top and is unkillable, > even with -9. After 20 minutes of such state I rebooted it with > + b > as nothing else would stop it. > Then I tried "touch t1" on the filesystem, with the same result. > + b again. > reboot won't work, as the partition would not unmount. only 4k blocksize seems to work now. fix is being prepared. -- Thanks, Vitaly Fertman
Re: reiser4progs 1.0.4
On Saturday 19 March 2005 21:03, Jindrich Makovicka wrote:
> Vitaly Fertman wrote:
> > On Friday 18 March 2005 21:59, Jindrich Makovicka wrote:
> >
> >>Vitaly Fertman wrote:
> >>
> >>>>so 1.0.3 & 1.0.4 bail out. Using fsck.reiser4 --build-sb from
> >>>>reiser4progs 1.0.3 rendered the filesystem created under 1.0.0 unusable,
> >>>
> >>>
> >>>fsck.reiser4 --build-sb is supposed to fix evth. what goes wrong?
> >>
> >>sorry I didn't replied earlier, but I didn't have a spare disk
> >>available. here it goes. 40GB partition was mkfs'ed with 1.0.0,
> >>populated somehow (about 32k files, 400MB), then fsck --build-sb from
> >>1.0.4 was run:
>
> I think I didn't run mkfs 1.0.4. I once tried debugfs.reiser4 -C on the
which progs version debugfs was from?
> test partition before fsck, as I had run it on one of my live partitions
> previously, because I originally thought it does the migration (the
> partition seems to have survived). Can this be the cause too? Is it
it should not, there were found fs super block backups of some previous
fs on the device you were fscking.
> still possible to migrate such partition to 1.0.4 or I should do full
> backup & dd if=/dev/zero /dev/hdXX & mkfs & restore?
the patch should be able to fix fs metadata. Run
fsck.reiser4 --build-fs --nomkid
--
Thanks,
Vitaly Fertman
= progs/fsck/fsck.c 1.160 vs edited =
--- 1.160/progs/fsck/fsck.c 2005-02-10 13:18:59 +03:00
+++ edited/progs/fsck/fsck.c 2005-03-21 14:36:06 +03:00
@@ -148,6 +148,7 @@ static errno_t fsck_init(fsck_parse_t *d
{"bitmap", required_argument, 0, 'B'},
{"unused", no_argument, NULL, 'u'},
{"oldfs", no_argument, NULL, 'O'},
+ {"nomkid", no_argument, NULL, 'N'},
{0, 0, 0, 0}
};
@@ -161,7 +162,7 @@ static errno_t fsck_init(fsck_parse_t *d
return USER_ERROR;
}
- while ((c = getopt_long(argc, argv, "L:VhnqafU:b:r?dB:plo:c:uyO",
+ while ((c = getopt_long(argc, argv, "L:VhnqafU:b:r?dB:plo:c:uyON",
options, &option_index)) >= 0)
{
switch (c) {
@@ -238,6 +239,9 @@ static errno_t fsck_init(fsck_parse_t *d
case 'O':
aal_set_bit(&data->options, FSCK_OPT_OLD);
break;
+ case 'N':
+ aal_set_bit(&data->options, FSCK_OPT_OLD);
+ break;
}
}
@@ -534,6 +538,7 @@ int main(int argc, char *argv[]) {
fsck_opt(&parse_data, FSCK_OPT_WHOLE) << REPAIR_WHOLE |
fsck_opt(&parse_data, FSCK_OPT_OLD) << REPAIR_WHOLE |
fsck_opt(&parse_data, FSCK_OPT_OLD) << REPAIR_NO_MKID |
+ fsck_opt(&parse_data, FSCK_OPT_NOMKID) << REPAIR_NO_MKID |
fsck_opt(&parse_data, FSCK_OPT_YES) << REPAIR_YES;
repair.bitmap_file = parse_data.bitmap_file;
= progs/fsck/fsck.h 1.28 vs edited =
--- 1.28/progs/fsck/fsck.h 2005-01-17 14:57:42 +03:00
+++ edited/progs/fsck/fsck.h 2005-03-21 14:33:42 +03:00
@@ -40,7 +40,8 @@ typedef enum fsck_options {
FSCK_OPT_RO = 0x3,
FSCK_OPT_DEBUG = 0x4,
FSCK_OPT_WHOLE = 0x5,
-FSCK_OPT_OLD = 0x6
+FSCK_OPT_OLD = 0x6,
+FSCK_OPT_NOMKID = 0x7
} fsck_options_t;
typedef struct fsck_parse {
Re: reiser4progs 1.0.4
On Friday 18 March 2005 21:59, Jindrich Makovicka wrote: > Vitaly Fertman wrote: > >>so 1.0.3 & 1.0.4 bail out. Using fsck.reiser4 --build-sb from > >>reiser4progs 1.0.3 rendered the filesystem created under 1.0.0 unusable, > > > > > > fsck.reiser4 --build-sb is supposed to fix evth. what goes wrong? > > sorry I didn't replied earlier, but I didn't have a spare disk > available. here it goes. 40GB partition was mkfs'ed with 1.0.0, > populated somehow (about 32k files, 400MB), then fsck --build-sb from > 1.0.4 was run: > > 8<--- snip > > holly:~# fsck.reiser4 --build-sb /dev/hdk1 > *** > This is an EXPERIMENTAL version of fsck.reiser4. Read README first. > *** > > Fscking the /dev/hdk1 block device. > > Will build the Reiser4 SuperBlock. > > Will check the consistency of the Reiser4 FileSystem. > > Continue? > > (Yes/No): Yes > * fsck.reiser4 started at Fri Mar 18 19:46:33 2005 > FSCK: UUID (0xea4de9160ad898572244086da443359e) found in the master > super block does not match the one found in the backup > (0xba44099ce147985c3da7d6bf7448b582). Fixed. > FSCK: The on-disk format mkfs id (0x19e74713) does not match the backup > one (0x75315ca). Fixed. > Reiser4 fs was detected on /dev/hdk1. it seems you forgot to mention that you had already created some reiser4 on this partition with 1.0.4 and after that created fs again with 1.0.0. the result of such experiments is that you have the mix of metadata -- fresh super blocks and old backup blocks. all formatted blocks are created according to the new parameters whereas recovery goes according to the detected backup blocks and as the result no valid reiser4 block is found. if you do not downgrade progs, you should not get such resuls. > Master super block (16): > magic: ReIsEr4 > blksize:4096 > format: 0x0 (format40) > uuid: 5c9847e1-9c09-44ba-82b5-4874bfd6a73d > label: > > Format super block (17): > plugin: format40 > description:Disk-format for reiser4. > magic: ReIsEr40FoRmAt > flushes:0 > mkfs id:0x75315ca > blocks: 9770662 > free blocks:9676935 > root block: 25 > tail policy:0x2 (smart) > next oid: 0x17d22 > file count: 32034 > tree height:4 > key policy: LARGE > > > CHECKING STORAGE TREE > > FSCK: Node (25): failed to open the root node. The whole filter pass is > skipped. > Warn : Reiser4 storage tree does not exist. Filter pass skipped. > > Read nodes 0 > > Nodes left in the tree 0 > Leaves of them 0, Twigs of them 0 > Invalid node pointers 1 > Time interval: Fri Mar 18 19:46:37 2005 - Fri Mar 18 19:46:37 2005 > CHECKING EXTENT REGIONS. > > Read twigs 0 > > Time interval: Fri Mar 18 19:46:37 2005 - Fri Mar 18 19:46:37 2005 > Warn : Fatal corruptions were found. Semantic pass is skipped. > > * fsck.reiser4 finished at Fri Mar 18 19:46:37 2005 > Closing fs...done > > 1 fatal corruptions were detected in FileSystem. Run with --build-fs > option to fix them. > > holly:~# fsck.reiser4 --build-sb /dev/hdk1 > ~/r4_buildsb.txt > *** > This is an EXPERIMENTAL version of fsck.reiser4. Read README first. > *** > > Fscking the /dev/hdk1 block device. > > Will build the Reiser4 SuperBlock. > > Will check the consistency of the Reiser4 FileSystem. > > Continue? > > (Yes/No): Yes > > holly:~# fsck.reiser4 --build-fs /dev/hdk1 > *** > This is an EXPERIMENTAL version of fsck.reiser4. Read README first. > *** > > Fscking the /dev/hdk1 block device. > > Will check the consistency of the Reiser4 SuperBlock. > > Will build the Reiser4 FileSystem. > > Continue? > > (Yes/No): Yes > * fsck.reiser4 started at Fri Mar 18 19:48:56 2005 > Reiser4 fs was detected on /dev/hdk1. > > Master super block (16): > magic: ReIsEr4 > blksize:4096 > format: 0x0 (format40) > uuid: 5c9847e1-9c09-44ba-82b5-4874bfd6a73d > label: > > Format super block (17): > plugin: format40 > description:Disk-format for reiser4. > magic: ReIsEr40FoRmAt > flushes:0 > mkfs id:0x75315ca > block
Re: Large Filesystem Support?
On Thursday 17 March 2005 03:32, Naveen Nathan wrote:
> > the patches change cofigure.in, so you need to run autoconf before
> > running confgure.
>
> I ran autoconf after applying the patch, and compiled libaal.
> I'm still receiving for both libaal & reiser4utils:
>
> checking for _FILE_OFFSET_BITS value needed for large files... no
> checking for _LARGE_FILES value needed for large files... no
>
> I've included a log for just for libaal.
would you apply this patch instead of the previous one to libaal.
--
Thanks,
Vitaly Fertman
= configure.in 1.52 vs edited =
--- 1.52/configure.in 2005-02-20 13:12:30 +03:00
+++ edited/configure.in 2005-03-14 17:20:41 +03:00
@@ -137,9 +136,12 @@ GENERIC_CFLAGS=""
GENERIC_CFLAGS="$GENERIC_CFLAGS -D_REENTRANT"
AC_SYS_LARGEFILE
-if test x${ac_cv_sys_file_offset_bits} != x; then
- GENERIC_CFLAGS="$GENERIC_CFLAGS -D_FILE_OFFSET_BITS=${ac_cv_sys_file_offset_bits}"
+if test -z "${ac_cv_sys_file_offset_bits}"; then
+ AC_MSG_WARN(Can't detect right _FILE_OFFSET_BITS. Will be forced to 64bit.)
+ ac_cv_sys_file_offset_bits=64
fi
+
+GENERIC_CFLAGS="$GENERIC_CFLAGS -D_FILE_OFFSET_BITS=${ac_cv_sys_file_offset_bits}"
AC_CHECK_SIZEOF(off_t, 64, [
#include
= src/file.c 1.16 vs edited =
--- 1.16/src/file.c 2004-09-22 17:46:59 +04:00
+++ edited/src/file.c 2005-03-17 15:44:53 +03:00
@@ -209,18 +209,8 @@ static count_t file_len(
return INVAL_BLK;
#ifdef BLKGETSIZE64
- if ((int)ioctl(*((int *)device->entity), BLKGETSIZE64, &size) >= (int)0) {
- uint32_t block_count;
-
- size = (size / 4096) * 4096 / device->blksize;
- block_count = size;
-
- if ((uint64_t)block_count != size) {
- aal_fatal("The partition size is too big.");
- return INVAL_BLK;
- }
-
- return (count_t)block_count;
+ if (ioctl(*((int *)device->entity), BLKGETSIZE64, &size) >= 0) {
+ return size / device->blksize;
}
#endif
@@ -231,8 +221,7 @@ static count_t file_len(
if (ioctl(*((int *)device->entity), BLKGETSIZE, &l_size) >= 0) {
size = l_size;
- return (count_t)((size * 512 / 4096) * 4096 /
-device->blksize);
+ return size * 512 / device->blksize;
}
}
Re: Large Filesystem Support?
On Wednesday 16 March 2005 04:29, Naveen Nathan wrote: > Thanks for the patch, however I do not think it's working (yet), and/or > there is some misconfiguration on our server. > > From both the unpatched and patched versions of libaal and reiser4progs > 1.0.4. > > > checking for _FILE_OFFSET_BITS value needed for large files... no > checking for _LARGE_FILES value needed for large files... no the patches change cofigure.in, so you need to run autoconf before running confgure. > I've included a typescript for the compile and install of both > libaal and the reiser 4 utils. This may help to analyze what > is going on. thanks for compilation warnings, a few wrong castings were fixed. > Also, it may be helpful, but I forgot to mention that the kernel > also has support for large block devices. I had also tried > reiser 3.6 and it could only make a 2.8TB partition. > > Regards, > Naveen Nathan -- Thanks, Vitaly Fertman
Re: Large Filesystem Support?
Hello,
what your configure tells about _FILE_OFFSET_BITS &
_LARGE_FILES? if it cannot detect the right value, probably
the attached patches for configure.in would help.
--
Thanks,
Vitaly Fertman
On Sunday 13 March 2005 12:13, Naveen Nathan wrote:
> Hey Reiser team & fellow Reiser users.
>
> iI have a system with 3x 3TB HW RAID5 volumes, using the latest
> 2.6.11.2 kernel & reiser4-utils 1.0.4.
>
> Using mdadm I've created a raid0 for all 3 volumes which is /dev/md0.
> This makes quite a large 9TB partition. Reading the FAQ on Reiser (3.6),
> I was expecting to be well within the limits of the 17TB partition size
> limit.
>
> These are the results from trying to create the partition:
>
> # mkfs.reiser4 /dev/md0
> mkfs.reiser4 1.0.4
> Copyright (C) 2001, 2002, 2003, 2004 by Hans Reiser, licensing governed by
> reiser4progs/COPYING.
>
> Block size 4096 will be used.
> Linux 2.6.11.2 is detected.
> Uuid f15dfd7a-8112-4f0a-96af-5ab781bdd2e4 will be used.
> Fatal: The partition size is too big.
> Reiser4 is going to be created on /dev/md0.
> (Yes/No): yes
> Fatal: The partition size is too big.
> Error: Can't initialize block allocator.
> Error: Can't create filesystem on /dev/md0.
>
> Unfortunately reiser4 cannot make the large partition. I have yet to use
> reiser3.6 assuming that reiser4 is the successor.
>
> Could someone please advise how I would get reiserfs on my large partition.
>
> Thanks,
> Naveen Nathan
>
>
= configure.in 1.52 vs edited =
--- 1.52/configure.in 2005-02-20 13:12:30 +03:00
+++ edited/configure.in 2005-03-14 17:20:41 +03:00
@@ -137,9 +136,12 @@ GENERIC_CFLAGS=""
GENERIC_CFLAGS="$GENERIC_CFLAGS -D_REENTRANT"
AC_SYS_LARGEFILE
-if test x${ac_cv_sys_file_offset_bits} != x; then
- GENERIC_CFLAGS="$GENERIC_CFLAGS -D_FILE_OFFSET_BITS=${ac_cv_sys_file_offset_bits}"
+if test -z "${ac_cv_sys_file_offset_bits}"; then
+ AC_MSG_WARN(Can't detect right _FILE_OFFSET_BITS. Will be forced to 64bit.)
+ ac_cv_sys_file_offset_bits=64
fi
+
+GENERIC_CFLAGS="$GENERIC_CFLAGS -D_FILE_OFFSET_BITS=${ac_cv_sys_file_offset_bits}"
AC_CHECK_SIZEOF(off_t, 64, [
#include
= configure.in 1.241 vs edited =
--- 1.241/configure.in 2005-02-20 13:10:00 +03:00
+++ edited/configure.in 2005-03-14 17:19:33 +03:00
@@ -417,9 +413,12 @@ fi
# Check for large file
AC_SYS_LARGEFILE
-if test x${ac_cv_sys_file_offset_bits} != x; then
- GENERIC_CFLAGS="$GENERIC_CFLAGS -D_FILE_OFFSET_BITS=${ac_cv_sys_file_offset_bits}"
+if test -z "${ac_cv_sys_file_offset_bits}"; then
+ AC_MSG_WARN(Can't detect right _FILE_OFFSET_BITS. Will be forced to 64bit.)
+ ac_cv_sys_file_offset_bits=64
fi
+
+GENERIC_CFLAGS="$GENERIC_CFLAGS -D_FILE_OFFSET_BITS=${ac_cv_sys_file_offset_bits}"
AC_CHECK_SIZEOF(off_t, 64, [
#include
Re: Reiser4 on Loop Device
On Wednesday 09 March 2005 10:47, Philipp Morger wrote: > Dear List, > > I'm having difficulties running reiser4 on a loop device: > > --(#:~)-- dd if=/dev/zero of=testfile bs=1M count=500 > 500+0 records in > 500+0 records out > --(#:~)-- losetup /dev/loop/0 testfile > --(#:~)-- losetup -a > /dev/loop/0: [0802]:55565837 (testfile) > --(#:~)-- mkfs.reiser4 /dev/loop/0 > mkfs.reiser4 0.4.18 > Copyright (C) 2001, 2002, 2003 by Hans Reiser, licensing governed by > reiser4progs/COPYING. > > Block size 4096 will be used. > Linux 2.6.11-rc5-mm1 is detected. > Uuid 7f5aa34e-c3b5-4463-85c4-b49f7a73176b will be used. > Reiser4 is going to be created on /dev/loop/0. > (Yes/No): Yes > Creating reiser4 on /dev/loop/0...done > --(#:~)-- fsck.reiser4 /dev/loop/0 > * > ** If you are using the latest reiser4progs and it fails ** > ** please email bug reports to reiserfs-list@namesys.com, ** > ** providing as much information as possible -- your ** > ** hardware, kernel, patches, settings, all reiserfsk ** > ** messages (including version), the reiser4fsck 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. ** > * > > Fscking the /dev/loop/0 block device. > Will check the consistency of the Reiser4 SuperBlock. > Will check the consistency of the Reiser4 FileSystem. > Will use (default) params. > Continue? > (Yes/No): Yes > * Openning the fs. > Fatal: Device operation "read" isn't implemented. > Fatal: Can't read master super block. > Fatal: Failed to open the master super block. > Fatal: Cannot open the FileSystem on (/dev/loop/0). > Segmentation fault > > > Versions in use: > > --(#:~)-- uname -a > Linux eternity 2.6.11-rc5-mm1 #1 Tue Mar 8 11:11:03 CET 2005 i686 Intel(R) > Pentium(R) 4 CPU 2.40GHz GenuineIntel GNU/Linux > > --(#:~)-- ldd /usr/sbin/mkfs.reiser4 > linux-gate.so.1 => (0xe000) > libreiser4-0.4.so.18 => /usr/lib/libreiser4-0.4.so.18 (0x4cd45000) > libaal-0.4.so.13 => /usr/lib/libaal-0.4.so.13 (0x4ccef000) > libuuid.so.1 => /lib/libuuid.so.1 (0xb7f28000) > libncurses.so.5 => /lib/libncurses.so.5 (0xb7ed1000) > libreadline.so.4 => /lib/libreadline.so.4 (0x467e6000) > libc.so.6 => /lib/libc.so.6 (0xb7da8000) > /lib/ld-linux.so.2 (0xb7f47000) please update your libaal & reiser4progs to the latest version. (ftp://ftp.namesys.com/pub/reiser4progs/) -- Thanks, Vitaly Fertman
Re: reiser4progs 1.0.4
On Monday 21 February 2005 17:35, Jindrich Makovicka wrote: > Ookhoi wrote: > > Fatal: Failed to open the reiser4 backup. > > Fatal: Cannot open the FileSystem on (/dev/hda1). > > > > 1 fatal corruptions were detected in SuperBlock. Run with --build-sb > > option to fix them. > > > Anyway, what is the preferred way to convert reiser4 to this new backup > layout? I have all reiser4 partitions created with reiserfsprogs 1.0.0, there was no format changes since 1.0.0, just a problem in reiser4progs with writing backups to disk > so 1.0.3 & 1.0.4 bail out. Using fsck.reiser4 --build-sb from > reiser4progs 1.0.3 rendered the filesystem created under 1.0.0 unusable, fsck.reiser4 --build-sb is supposed to fix evth. what goes wrong? > I still didn't try fsck 1.0.4. I also found the -C option of > debugfs.reiser4, but it didn't help either, and subsequent fsck also > botched the filesystem. Were there any fixes in 1.0.4 regarding this? -- Thanks, Vitaly Fertman
Re: reiser4progs 1.0.4
On Monday 21 February 2005 16:10, Ookhoi wrote: > On Sun, Feb 20, 2005 at 01:44:41PM +0300, Vitaly Fertman wrote: > > The new reiser4progs package is available on our ftp > > site (ftp://ftp.namesys.com/pub/reiser4progs/). > > Thank you for this release. It doesn't crash anymore :-) > > But it does tell me: > "NO REISER4 METADATA WERE FOUND. FS RECOVERY IS NOT POSSIBLE." > > I have a copy of the fs, but I did run verson 1.0.3 on it before > I made a copy. (1.0.3 crashes with segfault). > > Is this fs fixable you think? > > Thanks in advance and with kind regards, Sander > > > bellyup:~# fsck.reiser4 --version > fsck.reiser4 1.0.4 > Copyright (C) 2001, 2002, 2003, 2004 by Hans Reiser, licensing governed by > reiser4progs/COPYING. > > bellyup:~# fsck.reiser4 /dev/hda1 > *** > This is an EXPERIMENTAL version of fsck.reiser4. Read README first. > *** > > Fscking the /dev/hda1 block device. > Will check the consistency of the Reiser4 SuperBlock. > Will check the consistency of the Reiser4 FileSystem. > Continue? > (Yes/No): Yes > * fsck.reiser4 started at Mon Feb 21 13:49:30 2005 > Fatal: Wrong magic found in the master super block. > Fatal: Failed to open the reiser4 backup. > Fatal: Cannot open the FileSystem on (/dev/hda1). > > 1 fatal corruptions were detected in SuperBlock. Run with --build-sb option > to fix them. > > bellyup:~# fsck.reiser4 --build-sb /dev/hda1 > *** > This is an EXPERIMENTAL version of fsck.reiser4. Read README first. > *** > > Fscking the /dev/hda1 block device. > Will build the Reiser4 SuperBlock. > Will check the consistency of the Reiser4 FileSystem. > Continue? > (Yes/No): Yes > * fsck.reiser4 started at Mon Feb 21 13:49:43 2005 > Fatal: Wrong magic found in the master super block. > Fatal: Failed to open the reiser4 backup. > Fatal: Cannot open the FileSystem on (/dev/hda1). > > 1 fatal corruptions were detected in SuperBlock. Run with --build-sb option > to fix them. > > bellyup:~# fsck.reiser4 --build-sb /dev/hda1 > *** > This is an EXPERIMENTAL version of fsck.reiser4. Read README first. > *** > > Fscking the /dev/hda1 block device. > Will build the Reiser4 SuperBlock. > Will check the consistency of the Reiser4 FileSystem. > Continue? > (Yes/No): Yes > * fsck.reiser4 started at Mon Feb 21 13:49:43 2005 > Fatal: Wrong magic found in the master super block. > Master super block cannot be found on (/dev/hda1). Do you want to build a > new one? (Yes/No): Yes > Which block size do you use? [4096]: > Warn : A new master superblock is created on '/dev/hda1'. > Fatal: Can't open disk-format format40. > Enter the key plugin name [key_large]: > Enter the correct block count please [126504]: > Warn : The format 'format40' is created on '/dev/hda1'. > Error: Wrong magic is found in the filesystem status block. > Warn : Creating a new status block. > FSCK: Checksum missmatch in bitmap block 18. Checksum is 0x0, should be > 0xffc0001. FSCK: Checksum missmatch in bitmap block 32736. Checksum is > 0xef2d8782, should be 0x955c26fe. FSCK: Checksum missmatch in bitmap block > 65472. Checksum is 0x64c78fa2, should be 0xf55bf507. FSCK: Checksum > missmatch in bitmap block 98208. Checksum is 0xf6d9d7e3, should be > 0x885c0260. FSCK: Checksums will be fixed later. > Reiser4 fs was detected on /dev/hda1. > Master super block (16): > magic: ReIsEr4 > blksize:4096 > format: 0x0 (format40) > label: > > Format super block (17): > plugin: format40 > description:Disk-format for reiser4. > magic: ReIsEr40FoRmAt > flushes:0 > mkfs id:0xe78822c > blocks: 126504 > free blocks:0 > root block: 0 > tail policy:0x2 (smart) > next oid: 0x0 > file count: 0 > tree height:0 > key policy: LARGE > > > CHECKING STORAGE TREE > Warn : Reiser4 storage tree does not exist. Filter pass skipped. > Read nodes 0 > Nodes left in the tree 0 > Leaves of them 0, Twigs of them 0 > Invalid node pointers 1 > Time interval: Mon Feb 21 13:49:52 2005 - Mon Feb 21 13:49:52 2005 > CHECKING EXTENT REGIONS. > Read twigs 0 > Time interval: Mon Feb 21 13:49:52 2005 - Mon Feb
Re: Reiser4fs and SPARC64?
> libaal-1.0.4.tar.gz compiled fine without any patches. > but reiser4progs-1.0.4 did not (also no patches!): do you have a mix of several installed versions in the system? uninstall, check that nothing left and another try will probably help. > format40.c:255: warning: type defaults to `int' in declaration of `__tmp' > format40.c:255: warning: initialization makes integer from pointer > without a cast -- Thanks, Vitaly Fertman
reiser4progs 1.0.4
Hello All The new reiser4progs package is available on our ftp site (ftp://ftp.namesys.com/pub/reiser4progs/). It includes: Bugfixes: - in file body/extent item truncate code; - in backup handling & traverse code; - in journal unpack code; - in node repair code; - in not aligned access to on-disk data; - in extent item-by-item insertion code; - in tree balancing code; - in SuperBlock handling code; - in syncing code; - in file body convertion code. Enable libminimal by default. Do not configure/install empty utils(resizer, cpfs). A reiser4 support for grub 0.96 is available in ftp://ftp.namesys.com/pub/reiser4progs/grub -- Thanks, Vitaly Fertman
Re: new reiser4progs?
On Friday 18 February 2005 17:08, Ookhoi wrote: > On Fri, Feb 18, 2005 at 04:19:59PM +0300, Vitaly Fertman wrote: > > On Friday 18 February 2005 11:31, Ookhoi wrote: > > > Are new reiser4progs available? I can only find 1.0.3 as newest, > > > but that version is august 2004. wait, 1.0.3 was released in december 2004. -- Thanks, Vitaly Fertman
Re: new reiser4progs?
On Friday 18 February 2005 17:08, Ookhoi wrote: > On Fri, Feb 18, 2005 at 04:19:59PM +0300, Vitaly Fertman wrote: > > On Friday 18 February 2005 11:31, Ookhoi wrote: > > > Are new reiser4progs available? I can only find 1.0.3 as newest, > > > but that version is august 2004. > > > > I have been about to release it for some time, but new problems > > stoped me every time. > > I would love to try it. > > > > I get segmentation fault with --check of --build-sb, > > > and illegal instruction with --build-fs > > > > ok, I will release next version today or tomorrow and will see > > if it helps. > > If it is not too unconvenient for you to release it today, > that would make me a happy person. Of course I managed to > get the fs bellyup the day before I hop on a plane :-) > I hope a newer fsck.reiser4 prevents a time consuming reinstall. testing a release candidate before releasing. the amount of time needed depends on the amount of problems appeared, if debugging/fixing/bugfix testing is need, etc. -- Thanks, Vitaly Fertman
Re: new reiser4progs?
On Friday 18 February 2005 11:31, Ookhoi wrote: > Hello all, > > Are new reiser4progs available? I can only find 1.0.3 as newest, > but that version is august 2004. I have been about to release it for some time, but new problems stoped me every time. > It seems a newer version is provided to Simon, but in a private > mail, as I can't find that part of the thread in the archives: > http://www.mail-archive.com/reiserfs-list@namesys.com/msg16804.html > > I have the same problem described in that thread btw: > http://www.mail-archive.com/reiserfs-list@namesys.com/msg16785.html > > The thread starts here: > http://www.mail-archive.com/reiserfs-list@namesys.com/msg16777.html > > I get segmentation fault with --check of --build-sb, > and illegal instruction with --build-fs ok, I will release next version today or tomorrow and will see if it helps. > Kernel is 2.6.11-rc3-mm2. > > I'll read the archives so please reply to the list. Thanks in advance. > > With kind regards, Sander -- Thanks, Vitaly Fertman
Re: Reiser4fs and SPARC64?
On Wednesday 16 February 2005 17:09, Alex Zarochentsev wrote:
> On Wed, Feb 16, 2005 at 02:17:49PM +0100, [EMAIL PROTECTED] wrote:
> > Hi,
> >
> > i just wondered about reiser4fs working on SPARC64? I use Gentoo Sparc64
> > and it is working fine with kernel 2.4.28. But is the Reiser4 code
> > SPARC64 ready?
>
> It would be nice if you try it :) we have no reiser4/sparc64 reports yet.
>
> Reiser4 code is included into AKPM's -mm kernels. mkfs and other utils are
> in the ftp://ftp.namesys.com/pub/reiser4progs/
>
> At least 3 additional patches are needed for running reiser4 on sparc64.
> They not yet included into -mm kernels. I am attaching them to this
> e-mail.
and at least these 2 patches needs to applied also.
--
Thanks,
Vitaly Fertman
diff -rup libaal-1.0.3/include/aal/Makefile.am libaal-1.0.3-1/include/aal/Makefile.am
--- libaal-1.0.3/include/aal/Makefile.am 2004-01-08 15:49:40.0 +0100
+++ libaal-1.0.3-1/include/aal/Makefile.am 2005-01-16 22:18:51.0 +0100
@@ -2,4 +2,4 @@ aalincludedir = $(includedir)/aal
aalinclude_HEADERS = libaal.h device.h file.h exception.h list.h malloc.h \
print.h string.h math.h endian.h debug.h bitops.h \
- gauge.h block.h ui.h stream.h hash.h types.h
+ gauge.h block.h ui.h stream.h hash.h types.h unaligned.h
diff -rup libaal-1.0.3/include/aal/Makefile.in libaal-1.0.3-1/include/aal/Makefile.in
--- libaal-1.0.3/include/aal/Makefile.in 2004-12-06 19:04:14.0 +0100
+++ libaal-1.0.3-1/include/aal/Makefile.in 2005-01-16 15:24:49.0 +0100
@@ -146,7 +146,7 @@ aalincludedir = $(includedir)/aal
aalinclude_HEADERS = libaal.h device.h file.h exception.h list.h malloc.h \
print.h string.h math.h endian.h debug.h bitops.h \
- gauge.h block.h ui.h stream.h hash.h types.h
+ gauge.h block.h ui.h stream.h hash.h types.h unaligned.h
subdir = include/aal
ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
diff -rup libaal-1.0.3/include/aal/endian.h libaal-1.0.3-1/include/aal/endian.h
--- libaal-1.0.3/include/aal/endian.h 2003-07-27 10:55:29.0 +0200
+++ libaal-1.0.3-1/include/aal/endian.h 2005-01-16 22:29:19.0 +0100
@@ -75,8 +75,8 @@
#endif
-#define aal_get_leXX(xx, p, field) (LE##xx##_TO_CPU ((p)->field))
-#define aal_set_leXX(xx, p, field, val) ((p)->field = CPU_TO_LE##xx(val))
+#define aal_get_leXX(xx, p, field) (LE##xx##_TO_CPU (get_unaligned(&(p)->field)))
+#define aal_set_leXX(xx, p, field, val) put_unaligned(&(p)->field, CPU_TO_LE##xx(val))
#define aal_get_le16(p, field) aal_get_leXX(16, p, field)
#define aal_set_le16(p, field, val) aal_set_leXX(16, p, field, val)
diff -rup libaal-1.0.3/include/aal/libaal.h libaal-1.0.3-1/include/aal/libaal.h
--- libaal-1.0.3/include/aal/libaal.h 2004-09-22 14:27:23.0 +0200
+++ libaal-1.0.3-1/include/aal/libaal.h 2005-01-16 22:18:51.0 +0100
@@ -26,6 +26,7 @@ extern "C" {
#include "math.h"
#include "bitops.h"
#include "endian.h"
+#include "unaligned.h"
#include "debug.h"
#include "gauge.h"
#include "block.h"
diff -rup libaal-1.0.3/include/aal/unaligned.h libaal-1.0.3-1/include/aal/unaligned.h
--- libaal-1.0.3/include/aal/unaligned.h 2005-01-16 23:09:05.0 +0100
+++ libaal-1.0.3-1/include/aal/unaligned.h 2005-01-16 22:18:51.0 +0100
@@ -0,0 +1,26 @@
+/* Copyright (C) 2001-2005 by Hans Reiser, licensing governed by libaal/COPYING.
+
+ unaligned.h -- libaal unalignment declaration. */
+
+#ifdef HAVE_CONFIG_H
+# include
+#endif
+
+#ifndef AAL_UNALIGNED_H
+#define AAL_UNALIGNED_H
+
+#define get_unaligned(ptr)\
+({ \
+ __typeof__(*(ptr)) __tmp; \
+ aal_memcpy(&__tmp, (ptr), sizeof(*(ptr))); \
+ __tmp; \
+})
+
+#define put_unaligned(ptr, val)\
+({ \
+ __typeof__(*(ptr)) __tmp = (val); \
+ aal_memcpy((ptr), &__tmp, sizeof(*(ptr))); \
+ (void)0; \
+})
+
+#endif
diff -rup reiser4progs-1.0.3/plugin/item/cde40/cde40.h reiser4progs-1.0.3-1/plugin/item/cde40/cde40.h
--- reiser4progs-1.0.3/plugin/item/cde40/cde40.h 2004-06-30 01:42:33.0 +0200
+++ reiser4progs-1.0.3-1/plugin/item/cde40/cde40.h 2005-01-16 22:57:58.0 +0100
@@ -33,6 +33,7 @@ struct objid3 {
typedef struct objid3 objid3_t;
+
struct hash3 {
d8_t objectid[8];
d8_t offset[8];
@@ -130,71 +131,76 @@ extern uint32_t cde40_cut(reiser4_place_
extern uint16_t cde40_overhead();
#if defined(ENABLE_SHORT_KEYS) && defined(ENABLE_LARGE_KEYS)
+
+/* objidN_t macroses. */
+#define ob_loc(ob, pol) \
+ ((pol == 3) ? \
+ ((objid3_t *)(ob))->locality : \
+ ((objid4_t *)(ob))->locality)
+
#define ob_get_locality(ob, pol) \
-((pol == 3) ? \
- LE64_TO_CPU(*((d64_t *)((objid3_t *)(ob))->locality)) : \
- LE64_TO_CPU(*((d64_t *
Re: Partial data loss with reiserfs3
Hello, the history with some questions. do you have anything to add here? > I was trying to move data from my NTFS partition to Linux (Fedora Core > 3). I had 2GB ext3 partition for /home. After copying some files from > NTFS partition to /home (1) copy NTFS -> ext3 > and successfully shrinking NTFS partition by > 4GB I wanted to enlarge my /home. (2) shrink NTFS > NTFS was shrinked several reboots ago under Linux with > ntfsresize/fdisk. (3) reboot > Ext3 does not support partition > resize and move there, so I have decided to switch /home to ReiserFS > v3 (That's the version available for FC3) > > At this point the disk has, in order of physical layout: /dev/hda5 > (NTFS), 4GB /dev/hda6 (no FS), 2GB /dev/hda7 (reiser). was hda7 reiserfs or ext3 ?? > I've created 4GB Reiser partition (/dev/hda6) > It's very likely that mkfs was the first thing after boot. (4) create reiserfs on former NTFS, between NTFS and ext3 > and moved data there from old /home (/dev/hda7): > umount /home > mkdir /home.old > mount /dev/hda7 /home.old > mount /dev/hda6 /home > cd /home.old > find . -depth -print0 | cpio --null -pvd /home (5) copy ext3 -> reiserfs > It worked OK (as in "cpio did not fail and I could see my directories > and files") > > It is possible that I had created, copied, destroyed partitions > since last boot - but no repartitioning. this is not clear: created, destroyed partitions means repartitioning, changing parittion table means repartitioning. Do I understand correctly that you mean create, copy, destroy filesystems here? > Then I deleted my old /dev/hda7, and tried to enlarge /dev/hda6 to take > its space - by resizing partition, (6) fdisk: remove hda7, remove hda6, create large hda6; > then by resizefs.reiserfs. Resizefs complained about "Error: Can't resize > filesystem outside the device." no matter what I size I would try to expand > it, and with '-f' option too. It occured to me that perhaps reboot might > be required there, so I rebooted. (7) reboot > Bingo, after reboot resizefs enlarged partition to the size I wanted. > > # Size too big; missed the -f option > [EMAIL PROTECTED] ~]# resizefs.reiserfs /dev/hda6 +3G > Error: Can't resize filesystem outside the device. > > # Do the resize! > [EMAIL PROTECTED] ~]# resizefs.reiserfs -f /dev/hda6 +3G 3G just looks too large, there was only 2G hda7 as you have mentioned. right? (8) rezise.reiserfs > Reboot once again (9) reboot > and try to login with ordinary user (whose home is on that partition). > Login got to the point of KDE "Restoring session state" and then PC > hanged. (10) login failed > Hmm. Reboot and retry login with non-root user. The same. > Reboot and log-in as root. > > [EMAIL PROTECTED] ~]# umount /home > [EMAIL PROTECTED] ~]# reiserfsck /dev/hda6 (11) lots of fs corruptions. -- some lost file StatDatas -- some wrong delimiting keys -- some unformatted blocks are used more then once -- 1 formatted block is used more then once -- many broken bitmap blocks > I've never run 'reiserfsck --rebuild-sb'. progs 3.6.18 > > debugreiserfs /dev/hda6 > Count of blocks on the device: 1741036 > Number of bitmaps: 54 > Blocksize: 4096 > Free blocks (count of blocks - used [journal, bitmaps, data, reserved] > blocks):1696533 > Root block: 8212 when you run resizer, has it ever asked for confirmation? like 'Do you want to continue? [y/N]:' are you sure you have the relable memory? would you test it? the reason of the problem is not clear. resizer on expand writes only to _new_ bitmap blocks and overwrites only super block, and it does not touch the fs storage tree. so you can try to recover from the whole partition on the copy. Have you made fs/partition backup before rebuild-tree (probably fdisk)? If no, make a copy of the hda6 partition and run reiserfsck --rebuild-tree -S -l logfile if yes, copy it back to hda6 and run on hda6. -- Thanks, Vitaly Fertman
Re: Failed ReiserFS
> > > > On Thursday 10 February 2005 22.03, Vitaly Fertman wrote: > > > > > > > > reiserfsck 3.6.13 > > > > > > > > I used -S to scan the whole partition, as per man page > > > > > > > > A bug heh.. :( > > > > > > > > So is there any fix for it? > > > > > > > > > > > > > > Please try latest reiserfsck. > > > > > > > ftp://ftp.namesys.com/pub/reiserfsprogs/reiserfsprogs-3.6.19.ta > > > > > > >r. gz > > > > > > > > > > > > Same problem: > > > > > > > > > > > > lost+found.c 348 pass_3a_look_for_lost > > > > > > look_for_lost: The entry 'lost+found' could not be found in the > > > > > > root directory Aborted > > > > > > > > > > > > This is getting more than frustrating... > > > > > > > > > > would you pack the metadata with > > > > > debugreiserfs -p | bzip2 -c > -meta.bz2 > > > > > and provide them for downloading? > > > > > > > > the metadata and reiserfsck log are both available for download. > > > > > > > > ftp://ftp.rikjoh.com/reisercheck.logfile.bz2 > > > > ftp://ftp.rikjoh.com/hdc1-meta.bz2 > > > > > > Moved the disks to another computer with a clean install of Linux. > > > Reran the --rebuild-tree on that one. And i still get the same error > > > "look_for_lost: The entry 'lost+found' could not be found in the root" > > > And its the "reiserfs-3.6.13" package. > > > Still no luck :( > > > > > > Why cant it find the /lost+found ? > > > > no problem with your metadata. > > Are you sure you run reiserfsck 3.6.19? > > Did you obtain reiserfsprogs-3.6.19 from our ftp site? > > Would you check the memory on the computer you run reiserfsck > > on and would you check the harddrive for bad blocks? > > Just ran 3.6.19 on the fresh installed computer > Same error. > > -- > > Will rebuild the filesystem (/dev/hdc1) tree > Will put log info to '/root/reisercheck.logfile' > > Do you want to run this program?[N/Yes] (note need to type Yes if you > do):Yes Replaying journal.. > Reiserfs journal '/dev/hdc1' in blocks [18..8211]: 0 transactions replayed > ### > reiserfsck --rebuild-tree started at Mon Feb 14 21:05:44 2005 > ### > > Pass 0: > The whole partition (7504544 blocks) is to be scanned ah, wait, if you run reiserfsck with -S option then matadata needs to be dumped with -S also: debugreiserfs -p -S | bzip2 -c > -meta.bz2 -- Thanks, Vitaly Fertman
Re: Partial data loss with reiserfs3
On Monday 14 February 2005 19:38, Laurynas Biveinis wrote: > Cituojant Vitaly Fertman <[EMAIL PROTECTED]>: > > > [EMAIL PROTECTED] ~]# mkfs -t reiserfs /dev/hda6 > > > > did you shrink ntfs under win and reboot? > > NTFS was shrinked several reboots ago under Linux with > ntfsresize/fdisk. > > > what happened between the last boot and mkfs? > > I do not remember well and .bash_history isn't very helpful there. It's > very likely that mkfs was the first thing after boot. > > > did you run fdisk then? did you reboot after that fdisk run? > > I'm not sure what does "then" mean? After "mkfs -t reiserfs /dev/hda6"? > No, I didn't run fdisk or reboot then - I copied data. then meant before. ok, if you did not run fdisk between boot and mkreiserfs, then mount, copy, umount were probably fine. after that you run fidsk -- have you run 'reiserfsck --rebuild-sb' after fdisk? actually resize.reiserfs does not touch data on expand at all, it just writes bitmap blocks to the added part. what does debugreiserfs /dev/hda6 say? what version of reiserfsprogs do you use? -- Thanks, Vitaly Fertman
Re: Partial data loss with reiserfs3
On Monday 14 February 2005 17:40, Laurynas Biveinis wrote: > Hello, > > Cituojant Vitaly Fertman <[EMAIL PROTECTED]>: > > reboot is required between repartitioning a drive and starting to use > > > > moved/created partitions. without that the kernel may continue to > > use > > old partition table. so it would be great to recall step-by-step > > history > > of your copings, removes, repatitionings and reboots. > > Starting from the last successful cpio between old and new /home > partitions - can I assume that data was intact at this point if cpio > succeeded? > > At this point the disk has, in order of physical layout: /dev/hda5 > (NTFS), 4GB /dev/hda6 (no FS), 2GB /dev/hda7 (reiser). > > I tried my best to reconstruct this history, but there might be some > mistakes, of course. > > [EMAIL PROTECTED] ~]# mkfs -t reiserfs /dev/hda6 did you shrink ntfs under win and reboot? what happened between the last boot and mkfs? did you run fdisk then? did you reboot after that fdisk run? -- Thanks, Vitaly Fertman
Re: Partial data loss with reiserfs3
On Sunday 13 February 2005 20:29, Laurynas Biveinis wrote: > Hello, > > I was trying to move data from my NTFS partition to Linux (Fedora Core > 3). I had 2GB ext3 partition for /home. After copying some files from > NTFS partition to /home and successfully shrinking NTFS partition by > 4GB I wanted to enlarge my /home. Ext3 does not support partition > resize and move there, so I have decided to switch /home to ReiserFS > v3 (That's the version available for FC3) > > I've created 4GB Reiser partition (/dev/hda6) and moved data there from > old /home (/dev/hda7): > umount /home > mkdir /home.old > mount /dev/hda7 /home.old > mount /dev/hda6 /home > cd /home.old > find . -depth -print0 | cpio --null -pvd /home > > It worked OK (as in "cpio did not fail and I could see my directories > and files") > > Then I deleted my old /dev/hda7, and tried to enlarge /dev/hda6 to take > its space - by resizing partition, then by resizefs.reiserfs. Resizefs > complained about "Error: Can't resize filesystem outside the device." > no matter what I size I would try to expand it, and with '-f' option > too. It occured to me that perhaps reboot might be required there, so > I rebooted. Bingo, after reboot resizefs enlarged partition to the size > I wanted. Reboot once again and try to login with ordinary user (whose > home is on that partition). reboot is required between repartitioning a drive and starting to use moved/created partitions. without that the kernel may continue to use old partition table. so it would be great to recall step-by-step history of your copings, removes, repatitionings and reboots. > Login got to the point of KDE "Restoring session state" and then PC > hanged. Hmm. Reboot and retry login with non-root user. The same. > Reboot and log-in as root. > > [EMAIL PROTECTED] ~]# umount /home > [EMAIL PROTECTED] ~]# reiserfsck /dev/hda6 > > [See Output 1 below] > > OK, so it says --rebuild-tree... > > [EMAIL PROTECTED] ~]# reiserfsck --rebuild-tree /dev/hda6 > > [See Output 2 below] > > At this point I remounted partition read-only and looked around. And > that's it, part of my data is at lost+found, and part is gone. > Here was a typical mount /dev/hda6 output to syslog: > - > Feb 13 18:04:58 laurynas-pc kernel: ReiserFS: hda6: found reiserfs > format "3.6" with standard journal > Feb 13 18:04:58 laurynas-pc kernel: ReiserFS: hda6: using ordered data > mode > Feb 13 18:04:58 laurynas-pc kernel: ReiserFS: hda6: journal params: > device hda6, size 8192, journal first block 18, max trans len 1024, max > batch 900, max commit age 30, max trans age 30 > Feb 13 18:04:58 laurynas-pc kernel: ReiserFS: hda6: checking transaction > log (hda6) > Feb 13 18:04:58 laurynas-pc kernel: ReiserFS: hda6: replayed 17 > transactions in 0 seconds > Feb 13 18:04:58 laurynas-pc kernel: ReiserFS: hda6: Using r5 hash to > sort names > --- > > And one more line looks particularly interesting: > ------- > Feb 13 18:08:05 laurynas-pc kernel: ReiserFS: hda6: warning: vs-4080: > reiserfs_free_block: free_block (hda6:32998)[dev:blocknr]: bit already > cleared > --- > > Is there anything I can do to look for my other missing data? -- Thanks, Vitaly Fertman
Re: Failed ReiserFS
On Monday 14 February 2005 14:24, Rikard Johnels wrote: > On Friday 11 February 2005 08.57, Rikard Johnels wrote: > > On Thursday 10 February 2005 22.03, Vitaly Fertman wrote: > > > > > > reiserfsck 3.6.13 > > > > > > I used -S to scan the whole partition, as per man page > > > > > > A bug heh.. :( > > > > > > So is there any fix for it? > > > > > > > > > > Please try latest reiserfsck. > > > > > ftp://ftp.namesys.com/pub/reiserfsprogs/reiserfsprogs-3.6.19.tar.gz > > > > > > > > Same problem: > > > > > > > > lost+found.c 348 pass_3a_look_for_lost > > > > look_for_lost: The entry 'lost+found' could not be found in the root > > > > directory Aborted > > > > > > > > This is getting more than frustrating... > > > > > > would you pack the metadata with > > > debugreiserfs -p | bzip2 -c > -meta.bz2 > > > and provide them for downloading? > > > > the metadata and reiserfsck log are both available for download. > > > > ftp://ftp.rikjoh.com/reisercheck.logfile.bz2 > > ftp://ftp.rikjoh.com/hdc1-meta.bz2 > > Moved the disks to another computer with a clean install of Linux. > Reran the --rebuild-tree on that one. And i still get the same error > "look_for_lost: The entry 'lost+found' could not be found in the root" > And its the "reiserfs-3.6.13" package. > Still no luck :( > > Why cant it find the /lost+found ? no problem with your metadata. Are you sure you run reiserfsck 3.6.19? Did you obtain reiserfsprogs-3.6.19 from our ftp site? Would you check the memory on the computer you run reiserfsck on and would you check the harddrive for bad blocks? -- Thanks, Vitaly Fertman
Re: reiserfs3 rebuild-tree successful but no files
> > after rebuilding the tree, does 'reiserfsck --check ' see these
> > files?
>
> Yes, see my original email from 08.02.2005 23:21. The original output has a
> length of about 13000 lines. A extract looks like this:
>
> ...
> rebuild_semantic_pass: The entry [741258 1025777] ("www.firstname.de.ico")
> in directory [296134 741258] points to nowhere - is removed
> rewrite_file: 2 items of file [741258 1041142] moved to [741258 93475]
> The entry [741258 1041142] ("deltab.de.ico") in directory [296134 741258]
> updated to point to [741258 93475]
> rewrite_file: 2 items of file [741258 1041137] moved to [741258 93569]
> The entry [741258 1041137] ("www.bild.t-online.de.ico") in directory
> [296134 741258] updated to point to [741258 93569]
> ...
>
> The last lines:
>
> ...
> Flushing..finished
> Objects without names 18403
> Empty lost dirs removed 384
> Dirs linked to /lost+found: 2174
> Dirs without stat data found 83
> Files linked to /lost+found 16229
> Objects having used objectids: 49
> files fixed 47
> dirs fixed 2
> Pass 4 - finished done 1476, 37 /sec
> Deleted unreachable items 716
> Flushing..finished
> Syncing..finished
> ###
> reiserfsck finished at Tue Feb 8 17:40:05 2005
> ...
>
> Most of the files were removed by 'reiserfsck --check '.
besides the journal replay reiserfsck --check does not change
anything on the partition, RO checks only.
> > do you have a reiserfs support in the kernel?
>
> Sure, one of my data partition is reiserfs:
>
> ...
> [EMAIL PROTECTED]:~ 0$ # debugreiserfs -J /dev/hda7
> debugreiserfs 3.6.19 (2003 www.namesys.com)
>
>
> Filesystem state: consistency is not checked after last mounting
>
> Reiserfs super block in block 16 on 0x307 of format 3.6 with standard
> journal Count of blocks on the device: 4393769
> ...
>
> > what if you zero the first 64K with
> > dd conv=notrunc if=/dev/zero of= bs=4096 count=16
> > can you mount it now? (rebuild-tree should already complete by the mount
> > time).
>
> Hurray, this is the trick! I don't understand why, but I can see hundreds
> of directories and thousends of files. Thanks a lot!!!
>
> > do you have anything related in the syslog about the mount time?
>
> This is the first time 'dmesg' gives an output:
>
> ReiserFS: sdc5: found reiserfs format "3.6" with standard journal
> ReiserFS: sdc5: using ordered data mode
> ReiserFS: sdc5: journal params: device sdc5, size 8192, journal first block
> 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
> ReiserFS: sdc5: checking transaction log (sdc5)
> ReiserFS: sdc5: Using r5 hash to sort names
>
> Could you give me a technical describtion why this worked?
the kernel found an ext2 magic somewhere in the first 64K,
reiserfs keeps the super block on 64K offset, so ext2 one was
not overwritten by rebuild-sb. this is why it was mounted as ext2.
but why the kernel refused to mount as reiserfs when was explicitely
specified -- this is a bug.
--
Thanks,
Vitaly Fertman
Re: Failed ReiserFS
> > > reiserfsck 3.6.13 > > > I used -S to scan the whole partition, as per man page > > > A bug heh.. :( > > > So is there any fix for it? > > > > Please try latest reiserfsck. > > ftp://ftp.namesys.com/pub/reiserfsprogs/reiserfsprogs-3.6.19.tar.gz > > Same problem: > > lost+found.c 348 pass_3a_look_for_lost > look_for_lost: The entry 'lost+found' could not be found in the root > directory Aborted > > This is getting more than frustrating... would you pack the metadata with debugreiserfs -p | bzip2 -c > -meta.bz2 and provide them for downloading? -- Thanks, Vitaly Fertman
Re: reiserfs3 rebuild-tree successful but no files
> Okay, I've done two versions, one with and one without '-S'. I applied the > following commands to the image copy (the image itself is untouched, I > always worked with fresh copies): > > # reiserfsck -y /dev/loop/0 --rebuild-sb > # reiserfsck -y /dev/loop/0 --check > # reiserfsck -y /dev/loop/0 --rebuild-tree > # debugreiserfs -p /dev/loop/0 | bzip2 -c > meta.bz2 > # reiserfsck -y /dev/loop/0 --rebuild-tree -S > # debugreiserfs -p /dev/loop/0 | bzip2 -c > meta-S.bz2 > > Use ftp://80.133.138.104:12121 sorry, but I get 'no route to host' every time. -- Thanks, Vitaly Fertman
Re: reiserfs3 rebuild-tree successful but no files
On Thursday 10 February 2005 18:02, Christian Placzek wrote: > On Thursday 10 February 2005 15:09, you wrote: > > Hello. > > > > Christian Placzek wrote: > > >On Wednesday 09 February 2005 13:01, Vladimir Saveliev wrote: > > >>Hello > > >> > > >>On Wed, 2005-02-09 at 12:04, Christian Placzek wrote: > > >>>On Wednesday 09 February 2005 09:47, you wrote: > > >>>>Hello > > >>>> > > >>>>On Wed, 2005-02-09 at 01:21, Christian Placzek wrote: > > >>>>>Hello, > > >>>>> > > >>>>>a friend of mine shredded his data (70GB) when he tried to undelete > > >>>>>an accidentally deleted file. He normally works with windoze. > > >>>>>Therefore he didn't know he couldn't undelete a file on a reiserfs > > >>>>>partition with ext2 undelete tool %-( > > >>>>>When he called me it was already too late. He had overwritten the > > >>>>>superblock :-( > > >>>>> > > >>>>>I'm still trying to rescue the data. I can see them in the image > > >>>>>using grep or hexedit. But nothing I tried has been successful. My > > >>>>>first steps were unmounting the partition, taking an image and > > >>>>>working with a copy of this image using a loop back device. > > >>>>> > > >>>>>All files have been retrieved but were removed by reiserfsck --check > > >>>>>although the last output says that directories and files have been > > >>>>>linked (see below). I tried with many combinations nearly all > > >>>>>parameters of reiserfsck: --fix-fixable --no-journal-available -S > > >>>>> ... > > >>>> > > >>>>have you tried > > >>>>reiserfsck --rebuild-tree -S > > >>>>? > > >>>>If not, run it on newly created copy of shredded device. > > >>> > > >>>Yes, I did. The output of reiserfsck --rebuild-tree gave other numbers > > >>> of linked directories/files. But I can't see them. > > >>> > > >>>>Did you look at lost+found? > > >>> > > >>>Shure, see below. > > >> > > >>can you do > > >>debugreiserfs -p -S /dev/shredded | bzip2 -c > meta.bz2 > > > > > >Okay, I've done two versions, one with and one without '-S'. I applied > > > the following commands to the image copy (the image itself is > > > untouched, I always worked with fresh copies): > > > > > ># reiserfsck -y /dev/loop/0 --rebuild-sb > > ># reiserfsck -y /dev/loop/0 --check > > ># reiserfsck -y /dev/loop/0 --rebuild-tree > > > > > > Sorry, do I understand correctly that you tried to mount /dev/loop/0 > > with -t reiserfs option after __this__ reiserfsck --rebuild-tree? Not > > after the following ones? > > Let me explain my mode of operation: I make a copy of the original image > taken of the harddrive. Then I use 'losetup' or 'mount -o loop' in order to > mount the image as device. Next I perform different operations using > 'reiserfsck'. Above you see _one_ possiblity. Then I mount the image as > filesystem using 'mount -o ro /dev/loop/0 /mnt/temp1/', and, as I described > below, I get no directories or files. Mounting with '-t reiserfs' always > result in following output: > > mount: wrong fs type, bad option, bad superblock on /dev/loop/0, >or too many mounted file systems after rebuilding the tree, does 'reiserfsck --check ' see these files? do you have a reiserfs support in the kernel? what if you zero the first 64K with dd conv=notrunc if=/dev/zero of= bs=4096 count=16 can you mount it now? (rebuild-tree should already complete by the mount time). do you have anything related in the syslog about the mount time? -- Thanks, Vitaly Fertman
Re: Patch to fix typos in reiser4progs 1.0.3
On Thursday 10 February 2005 00:19, Peter Klotz wrote: > I attached a patch that fixes a few typos in reiser4progs 1.0.3. Thanks a lot, applying it. Vitaly Fertman
Re: reiserfsck hangs (reiser3)
On Tuesday 08 February 2005 02:10, Michael P. Cosby wrote: > Short description: > reiserfsck --rebuild-tree hangs for over 24 hours while attempting to > repair my filesystem. This happens no matter how many times I run > reiserfsck v3.6.19 > > Environment: > linux 2.6.10 (debian) > reiserfsck v3.6.19 > resize_reiserfs v3.6.19 > LVM (v2.6 style) > > long description: > I had 3 200GB drives joined together into a single partition via LVM, > with reiserfs on top of that. At the time I was using kernel 2.6.8.1. > Timeline: > > First day > - > * one drive in the LVM began giving me bad sector errors > * bought a new drive to replace it that was 3GB smaller > * attempted to resize the reiser fs, which failed due to bad sectors > * bought a different new drive, used LVM (pvmove) to move the data from the > failing drive to the new one > * verified the disk I took out was bad, got an RMA and shipped it back > * ran reiserfsck, which completed and gave me the "use --rebuild-tree > option" * ran reiserfsck with rebuild-tree, got bad sector errors from > another drive (I've since decided my problem was overheating). > > A few days later (and then some) > - > * got another drive to replace the second failing drive, used LVM (pvmove) > to copy the data from the failing drive to the new one > * ran reiserfsck --rebuild-tree > * about 45% of the way through pass 2, reiserfsck hangs. Random samples > show it using between 40 and 70% of processor time, giving me the > impression it's not really hung (I expect a program that's actually hung to > use either 0% of 100% cpu time). So I left it for about 6 hours, stopped it > and tried again. This time I tried it with the -S switch and it hung, but > in a different spot. At that point I upgraded to linux 2.6.10. I tried it > again and left it for 12 hours before I had to reboot (to take the bad > drive out). I ran it a fourth time, added the -z option, and waited a full > 24 hours, after which I've come to the conclusion that it really is hung. > > I've attached the logfile from the last run. If you need any more > information or need me to run tests, please let me know. I can send you any > portion of the disk that you need (the data on it is not particularly > sensitive) but of course it's hard to send the full 600GB worth of raw data > :) > > Thank you very much for any help you can provide. let's try to pack the fs metadata with: debugreiserfs -p | bzip2 -c > -meta.bz2 they probably will be not so large for downloading. -- Thanks, Vitaly Fertman
Re: missing files?
On Monday 07 February 2005 18:58, Michael Styer wrote: > On Monday, 07 February, 2005 10:38 AM Vitaly Fertman wrote: > > On Saturday 05 February 2005 19:31, Michael Styer wrote: > >> OK. So I killed everything that was keeping /usr busy and unmounted it. > >> I ran debugfs.reiser4 on /dev/hdb1 unmounted. Then I mounted the > >> partition ( 'mount -t reiser 4 -o ro,noatime /dev/hdb1 /usr' ). Now > >> debugfs.reiser4 dies with this output: > >> > >> Fatal: Can't read master super block. Error: Can't open reiser4 > >> on /usr > >> > >> and fsck.reiser4 says this: > >> > >> Fatal: Can't read master superblock. Fatal: Failed to open the > >> reiser4 backup. Fatal: Cannot open the FileSysten on (/usr). > >> > >> 1 fatal corruptions were detected in SuperBlock. Run with --build-sb > >> option to fix them. > > > > what version of reiser4progs have you created this fs with? > > it looks like the version 1.0.3 cannot open the fs due to some > > changes in the format. > > I'm not entirely sure when I built this filesystem, but my guess is it was > version 1.0.2. > > >> Regarding the output of fsck.reiser4, it suggests to run fsck.reiser4 > >> --build-sb. What's that going to do to my filesystem? Am I likely to > >> lose the contents (i.e. is it like reformatting) or will it fix the > >> structure without causing data loss? At the minute it seems I still have > >> access to the filesystem, so I could tar everything up now before > >> rebuilding the superblock if doing so would mean losing that data. > > > > backups are never useless. > > Yes, a good point. > > >> Do you have any suggestions or advice as to what I should do from here? > > > > it depends on the reiser4progs version you created the fs with. > > if it was 1.0.2, you can just run 'fsck.reiser4 --build-sb ', > > of the 1.0.3 version, it will add reiser4 backup info properly. > > Do you mean, if I did create the fs with reiser4progs 1.0.2 I can now run > version 1.0.3 of fsck.reiser4 with the --build-sb option and it will do the > right thing? yes. > > if nothing has been changed on the fs since mas.devhdb1_unmounted.bz2 > > was created, you will get 2 fs corruptions that can be fixed with > > 'fsck.reiser4 --build-fs ' only. about 90 leaves will be cut off > > the tree and will be inserted leaf-by-leaf and after that not inserted > > item-by-item. > > > > btw, it is possible to run > > fsck.reiser4 --build-sb --build-fs > > to fix it all together. > > Just to confirm, I can do this using my current version 1.0.3 of > reiser4progs yes, you should use the latest reiser4progs, 1.0.3. > even if I created the fs with version 1.0.2? And I'm assuming > I have to have the fs mounted ro to do this, correct? Or should I unmount > the fs completely before doing this? you may keep it ro mounted if you want to, or unmouted. -- Thanks, Vitaly Fertman
Re: missing files?
On Saturday 05 February 2005 19:31, Michael Styer wrote: > On Fri, 4 Feb 2005, Vitaly Fertman said: > > so what I do not understand is why reiserfsck does not report any > > problem to you. Which reiserfsprogs do you have? have you 'umount & > > mount ro' or 'remount,ro', btw? reiser4 does not do 'remount,ro' > > properly yet. have you run fsck.reiser4 on umounted fs? > > Hmm. I did 'remount,ro', actually; didn't realize that it wouldn't work > with reiser4. I have version 1.0.3 of the Gentoo reiser4progs package; > fsck.reiser4, mkfs.reiser4 and debugfs.reiser4 all report version 1.0.3. > I concluded that fsck.reiser4 wasn't reporting problems just on the > basis of the lack of problems noted in the /var/log/messages output on > boot, but I hadn't run it manually. > > OK. So I killed everything that was keeping /usr busy and unmounted it. > I ran debugfs.reiser4 on /dev/hdb1 unmounted. Then I mounted the > partition ( 'mount -t reiser 4 -o ro,noatime /dev/hdb1 /usr' ). Now > debugfs.reiser4 dies with this output: > > Fatal: Can't read master super block. Error: Can't open > reiser4 on /usr > > and fsck.reiser4 says this: > > Fatal: Can't read master superblock. Fatal: Failed to open the > reiser4 backup. Fatal: Cannot open the FileSysten on (/usr). > > 1 fatal corruptions were detected in SuperBlock. Run with --build-sb > option to fix them. what version of reiser4progs have you created this fs with? it looks like the version 1.0.3 cannot open the fs due to some changes in the format. > I have the output of my first debugfs run if that would be helpful. I'll > put it up for download on the same IP with the filename of > mas.devhdb1_unmounted.bz2. I'm going to reboot so that you can get that > file (this is my webserver as well...). ok > Regarding the output of fsck.reiser4, it suggests to run fsck.reiser4 > --build-sb. What's that going to do to my filesystem? Am I likely to > lose the contents (i.e. is it like reformatting) or will it fix the > structure without causing data loss? At the minute it seems I still have > access to the filesystem, so I could tar everything up now before > rebuilding the superblock if doing so would mean losing that data. backups are never useless. > Do you have any suggestions or advice as to what I should do from here? it depends on the reiser4progs version you created the fs with. if it was 1.0.2, you can just run 'fsck.reiser4 --build-sb ', of the 1.0.3 version, it will add reiser4 backup info properly. if nothing has been changed on the fs since mas.devhdb1_unmounted.bz2 was created, you will get 2 fs corruptions that can be fixed with 'fsck.reiser4 --build-fs ' only. about 90 leaves will be cut off the tree and will be inserted leaf-by-leaf and after that not inserted item-by-item. btw, it is possible to run fsck.reiser4 --build-sb --build-fs to fix it all together. > Thanks very much for your help; I appreciate your taking the time to > help me out with this. > > Michael > > PS: I've included the list address again in case this discussion might > be helpful to anyone else. -- Thanks, Vitaly Fertman
Re: missing files?
On Wednesday 02 February 2005 19:25, Michael Styer wrote: > On Wed, 2 Feb 2005 19:10:15 +0300, "Vitaly Fertman" <[EMAIL PROTECTED]> > > said: > > would you pack the metadata with debugfs.reiser4 -P | > > bzip2 -c > .bz2 and let us to download them? > > Is it possible to do this when the device is mounted rw without causing > problems? Or would I have to unmount it and remount it ro? yes, umount and mount ro. -- Thanks, Vitaly Fertman
Re: missing files?
On Wednesday 02 February 2005 17:18, [EMAIL PROTECTED] wrote: > On Wed, 02 Feb 2005 00:33:07 -0500, [EMAIL PROTECTED] said: > > > Can anyone explain why this might have happened and what I might be > > > able to do to fix it? > > > > Sounds like wonky file permissions on the directory - lack of write > > permission *on the directory* will cause 'rm' to fail. Remember that > > renaming the directory requires write permission *on it's parent*, not > > on itself. > > No, that's not it, but thanks for the suggestion. I'm doing this as root > and the directory is 755, so I should be able to remove the files no > problem. Also rm -f doesn't complain it can't remove it, just returns > with no output. But afterward ls still reports the directory is there, > and ls -l still can't find it. > > Eg. > > # ls parent/ > target > # ls -l parent/ > ls: parent/target: No such file or directory > # rm -f parent/target > # ls parent/ > target > # ls -l parent/ > ls: parent/target: No such file or directory > # ls -ld parent/ > drwxr-xr-x 174 root root 174 Feb 1 23:30 parent/ > > On Wed, 02 Feb 2005 14:08:40 +0300, "Vladimir Saveliev" <[EMAIL PROTECTED]> > > said: > > Hello > > > > Is there anything about reiser4 in kernel logs? > > Yes, in fact; there are lots of messages nearly identical to this: > > Feb 2 03:19:31 apollo reiser4[rsync(17957)]: key_warning > (fs/reiser4/plugin/object.c:97)[nikita-717]: > Feb 2 03:19:31 apollo WARNING: Error for inode 483238 (-2) > > The only difference between the messages is the process name and pid, > and the inode number (well, and the date and time, obviously). > > Does that help? would you pack the metadata with debugfs.reiser4 -P | bzip2 -c > .bz2 and let us to download them? -- Thanks, Vitaly Fertman
Re: bad_unaligned_access_length in compiling reiserfsck for mips
On Sunday 30 January 2005 05:53, Kevin Turner wrote: > My cross-compile dies when it tries to link reiserfsck: > check_tree.o(.text+0x3a80): In function `__put_unaligned': > check_tree.c: undefined reference to `bad_unaligned_access_length' > > That error is from asm/unaligned.h, and is supposed to mean that someone > tried to put_unaligned something that wasn't 1, 2, 4, or 8 bytes, but > the code in check_tree.c looks to me like its using it with __u32, so > I'm stumped. > > reiserfsprogs version: 3.6.19 > linux-libc-headers version: 2.6.8.1 > > Host: linux-i686 > Target: linux-mipsel > Compiler: gcc 3.3.4 > compilation flags: > -fexpensive-optimizations -fomit-frame-pointer -frename-registers -O2 trying to reproduce it. what packages for mipsel cross compiling have you installed? probably some cross headers are needed also... -- Thanks, Vitaly Fertman
Re: reiserfsprogs did not solve my suse9.1pro problems
On Wednesday 26 January 2005 07:40, Roger Parmenter wrote: > Gentlemen; > > I have a problem with the root filesystem on my Suse 9.1pro partition. I > have downloaded your latest reiserfsprogs and ran the reiserfsck program > on the /dev/hdb5 (the root filesystem). This did not clear the partition > so that it could be mounted and the OS startup properly. > > I have kept good notes and some files to show you what went wrong. > > I'm happy to comment further if this will help the team. The hardware > involved is AMD 64 athlon chip. > > Looking forward to hearing from a member of the team. yes, it would be great to hear the whole story. -- Thanks, Vitaly Fertman
Re: why --rebuilt-tree says it's correcting errors but then those same exact errors show up again and again
incorrect, should be (4072) - corrected ..block > 4104106: The number of items (63) is incorrect, should be (1) - corrected > block 4104106: The free space (65280) is incorrect, should be (4048) - > corrected pass0: vpf-10110: block 4104106, item (0): Unknown item type > found [33488897 130816 0xff0001ff ??? (15)] - deleted block 4115015: The > free space (2647) is incorrect, should be (4072) - corrected block 4179064: > The free space (0) is incorrect, should be (4072) - corrected > ..60%80%...block 7583485: The number of items (33808) is incorrect, > should be (1) - corrected block 7583485: The free space (0) is incorrect, > should be (4048) - corrected pass0: vpf-10110: block 7583485, item (0): > Unknown item type found [16799326 16777472 0x5e521042210 ??? (6)] - > deleted .100% > 147053 directory entries were hashed with "r5" hash. > "r5" hash is selected > Flushing..finished > Read blocks (but not data blocks) 5748803 > Leaves among those 18650 > - leaves all contents of which could not be > saved and deleted 13 Objectids found 147055 > > Pass 1 (will try to insert 18637 leaves): > ### Pass 1 ### > Looking for allocable blocks .. finished > 0%20%40%60%80%100% > Flushing..finished > 18637 leaves read > 18591 inserted > 46 not inserted > ### Pass 2 ### > > Pass 2: > 0%20%40%60%80%100% > Flushing..finished > Leaves inserted item by item 46 > Pass 3 (semantic): > ### Pass 3 # > Flushing..finished > Files found: 62444 > Directories found: 6304 > Symlinks found: 78293 > Others: 13 > Pass 3a (looking for lost dir/files): > ### Pass 3a (lost+found pass) # > Looking for lost directories: > Flushing..finished > Pass 4 - finished > Flushing..finished > Syncing..finished > ### > reiserfsck finished at Sat Jan 22 05:50:19 2005 > ### > (none):~ # > > > > Also, further testing on a 2nd mirror copied disk shows the same exact > errors even after I run it twice in a row. > > > Best Regards, > Rob > > -- > Robert Harnaga > www.GriffinRUN.com > Game server hosting for serious players -- Thanks, Vitaly Fertman --- Begin Message --- On Saturday 08 January 2005 03:44, hanasaki wrote: > Could you outline exactly what takes place on a rebuild-tree? reiserfs has two types of blocks. There are unformatted nodes. They contain plain user file data. And there are formatted nodes. These may contain both user file data and filesystem metadata. --rebuild-tree scans all blocks looking for filesystem metadata, e.g. for formatted nodes. However you can put a reiserfs image into a file, then file data (e.g. unformatted nodes of the host fs) will contain formatted nodes of the fs image, and rebuilding of the host fs will be screwed up as there is no way to distinguish image fs metadata kept in unformatted nodes of the host fs from the host fs metadata. > I was under the incorrect assumption that if a rebuild-tree is 100% > successful then the FS is ok and a subsequent rebuild-tree will have > nothing to fix/report. . In your case, some unformatted nodes look like formatted ones for the first sight, however after fixing all the corruptions in these nodes fsck realises that there is no valid metadata left and that they are either completely broken nodes or file data ones. To not corrupt file data fsck does not flush the made changes on disk. And as nothing gets changed the same attempt of fixing these nodes repeats again on the next rebuild. > Vitaly Fertman wrote: > > On Tuesday 04 January 2005 20:25, hanasaki wrote: > >>Version of reiserfsk > >>== > >>== From debian sarge > >>/sbin/reiserfsck -V > >>reiserfsck 3.6.19 (2003 www.namesys.com) > >>== also used the version in knoppix 3.7 with similar results > >> > >>the output of two consecutive runs of --rebuild-tree on the same > >>unmounted partition are attached. Below is the diff > > > > rebuild-tree finds some blocks that looks like reiserfs formatted > > blocks for the first sight whereas they are not and just belongs to > > some file bodies. The consistency check reveals no valid metadata > > in them, so they are considered as not valid reiserfs formatted blocks > > and left not modified on disk. This is why the second run of rebuild-tree > > finds them again and tries to do all the stuff again. -- Thanks, Vitaly Fertman --- End Message ---
Re: Bug#289747: reiser4progs: mkfs.reiser4 is broken on sparc64
On Thursday 13 January 2005 16:19, Domenico Andreoli wrote: > hi, > > i received a bug report against reiser4progs 1.0.3-1 debian package. it has no extra patches, hasn't it? > i'm able to reproduce it on a UltraSparc IIi i can use to do > some testing. > > tell me if i can be of help in ironing the bug. ok, below. thanks for the help. > cheers > domenico > > > $ dd if=/dev/zero of=/tmp/reiser4.fuckup bs=1M count=100 > $ gdb /sbin/mkfs.reiser4 > GNU gdb 6.3-debian > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you > are welcome to change it and/or distribute copies of it under certain > conditions. Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "sparc-linux"...Using host libthread_db library > "/lib/libthread_db.so.1". > > (gdb) set args -f /tmp/reiser4.fuckup > (gdb) r > Starting program: /sbin/mkfs.reiser4 -f /tmp/reiser4.fuckup > /sbin/mkfs.reiser4 1.0.3 > Copyright (C) 2001, 2002, 2003, 2004 by Hans Reiser, licensing governed by > reiser4progs/COPYING. > > Block size 8192 will be used. > Linux 2.4.26-sparc64 is detected. > Uuid 51d06fc7-ea17-4ef1-ae6d-0b7f2b9d50f5 will be used. > Reiser4 is going to be created on /tmp/reiser4.fuckup. > (Yes/No): yes > Creating reiser4 on /tmp/reiser4.fuckup ... > Program received signal SIGBUS, Bus error. > 0x00063d20 in cde40_insert_units (place=0xefff9798, hint=0xefffbd28) at > cde40.c:761 761 ha_set_ordering(entry, ord, pol); p cde40_units(place) p *place p *hint p entry - place->block->body p i p pol [if pol == 3] p *(hash3_t *)entry [if pol == 4] p *(hash4_t *)entry or a remote access to the computer > (gdb) bt > #0 0x00063d20 in cde40_insert_units (place=0xefff9798, hint=0xefffbd28) at > cde40.c:761 #1 0x00052d04 in node40_modify (entity=0xc6d48, pos=0xc6bd8, > hint=0xefffbd28, modify_func=0x639e4 ) at node40.c:637 > #2 0x00052e24 in node40_insert (entity=0xc6d48, pos=0xc6bd8, > hint=0xefffbd28) at node40.c:661 #3 0x00094b74 in cb_node_insert > (node=0xc6d48, pos=0xc6bd8, hint=0xefffbd28) at node.c:440 #4 0x00094ae8 > in reiser4_node_modify (node=0xc6d48, pos=0xc6bd8, hint=0xefffbd28, > modify_func=0x94b40 ) at node.c:433 #5 0x0001e4a0 in > reiser4_tree_modify (tree=0xc68f0, place=0xc6bd8, hint=0xefffbd28, level=1 > '\001', estimate_func=0x1e100 , modify_func=0x94b40 > ) at tree.c:2866 #6 0x0001e8d4 in reiser4_tree_insert > (tree=0xc68f0, place=0xc6bd8, hint=0xefffbd28, level=1 '\001') at > tree.c:2959 #7 0x00013798 in tree_insert (tree=0xc68f0, place=0xc6bd8, > hint=0xefffbd28, level=1 '\001') at libreiser4.c:41 #8 0x000983f4 in > obj40_insert (obj=0xc6ac8, place=0xc6bd8, hint=0xefffbd28, level=1 '\001') > at obj40.c:657 #9 0x000845b8 in dir40_create (hint=0xefffbeb8) at > dir40.c:527 > #10 0x00020fcc in reiser4_object_create (entry=0xefffbfd8, hint=0xefffbeb8) > at object.c:425 #11 0x0001165c in reiser4_root_create (fs=0xc5e18) at > mkfs.c:99 > #12 0x0001339c in main (argc=3, argv=0xe5c4) at mkfs.c:467 > (gdb) -- Thanks, Vitaly Fertman
