Re: Problems with reiserfs when start OpenAFS 1.2.11-fc1 Segmentation fault with kernel 2.4.22-1.2174.nptl
On Wed, Mar 03, 2004 at 07:00:06PM -0600, jds wrote:
> Hi: Iam compile OpenAFS 1.2.11-fc1 with kernel 2.4.22-1.2174.nptl is OK
>
> problems with reiserfs 3.6 and Fedora Core 1
> the problems is when start the client AFS recive the messages:
>
> [EMAIL PROTECTED] modload]# service afs start
> Found libafs-2.4.22-1.2174.nptl-i686.o from SymTable... Loading...
> Starting AFS services.
> /etc/init.d/afs: line 305: 3300 Segmentation fault /usr/vice/etc/afsd
> ${AFSD_OPTIONS}
You can't use the OpenAFS client on a ReiserFS filesystem. It currently
only supports ext2/ext3 filesystems. If you only have reiser
filesystems, just make a big empty file:
# dd if=/dev/zero of=/var/afscache
and make an ext2 filesystem on it:
# mke2fs -F /var/afscache
and loop-mount it wherever your afs cache needs to be.
# mount -o loop,rw /var/afscache /usr/vice/cache
You can automate this in your fstab:
/var/afscache /usr/vice/cache ext2 defaults,loop 0 0
--
Ryan Underwood, <[EMAIL PROTECTED]>
signature.asc
Description: Digital signature
Re: Bugs on big endian systems
Thanks Jeff and Pavel. Nikita, send Pavel the usual agreement, and
we'll send to Linus unless someone finds an objection. Edward, read
this patch, test it on alpha,
and approve it. Elena, test it on x86.
Hans
Jeff Mahoney wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Pavel -
Thanks. The good news is that the filesystem wouldn't have panicked
because of the SB_ONDISK_RESERVED_FOR_JOURNAL(s) bug. The bad news is
that it wouldn't have mattered because the filesystem could never have
been mounted anyway due to the journal header version mismatch.
I'm surprised nobody's ever tried to mount a relocated journal enabled
filesystem on a big endian machine.
Hans -
This bug appears in both 2.4 and 2.6 kernels and should be fixed in both.
- -Jeff
Pavel Bartusek wrote:
| Hi list,
|
| The attached patch will fix the bugs which appears only on big endian
| systems in the kernel 2.4.25.
|
| regards
|
|
| Pavel Bartusek
| Software Engineering
|
| SYSGO Real-Time Solutions AG | Embedded and Real-Time Software
| Lise-Meitner-Str.15
| 89081 Ulm, Germany
|
| Voice: +49-731-9533-1295
| FAX: +49-731-94683-10
| www.sysgo.com | www.elinos.com | www.osek.de
|
|
|
|
| --- linux.ori/fs/reiserfs/journal.cMon Aug 25 13:44:43 2003
| +++ linux/fs/reiserfs/journal.cWed Mar 3 13:26:23 2004
| @@ -2094,7 +2094,7 @@
|
| /* make sure that journal matches to the super block */
| if (is_reiserfs_jr(rs) &&
| -jh->jh_journal.jp_journal_magic != sb_jp_journal_magic(rs)) {
| +le32_to_cpu (jh->jh_journal.jp_journal_magic) !=
sb_jp_journal_magic(rs)) {
| char jname[ 32 ];
| char fname[ 32 ];
|
| @@ -2102,7 +2102,7 @@
| strcpy( fname, kdevname( p_s_sb->s_dev ) );
| printk("journal-460: journal header magic %x (device %s) does
not "
| "match magic found in super block %x (device %s)\n",
| -jh->jh_journal.jp_journal_magic, jname,
| +le32_to_cpu (jh->jh_journal.jp_journal_magic), jname,
| sb_jp_journal_magic(rs), fname);
| brelse (bhjh);
| goto free_and_return;
| --- linux.ori/include/linux/reiserfs_fs.hMon Aug 25 13:44:44 2003
| +++ linux/include/linux/reiserfs_fs.hWed Mar 3 13:25:45 2004
| @@ -219,7 +219,7 @@
| #define SB_ONDISK_JOURNAL_DEVICE(s) \
| le32_to_cpu ((SB_ONDISK_JP(s)->jp_journal_dev))
| #define SB_ONDISK_RESERVED_FOR_JOURNAL(s) \
| - le32_to_cpu
((SB_V1_DISK_SUPER_BLOCK(s)->s_reserved_for_journal))
| + le16_to_cpu
((SB_V1_DISK_SUPER_BLOCK(s)->s_reserved_for_journal))
|
| #define is_block_in_log_or_reserved_area(s, block) \
| block >= SB_JOURNAL_1st_RESERVED_BLOCK(s) \
- --
Jeff Mahoney
SuSE Labs
[EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFARk4/LPWxlyuTD7IRAkIZAJ0VR8aYna2n3EK/BfZ2SBwKOe9OPQCfYzDH
c8D4gSwDzr93HivtH2FMx5M=
=Jj1U
-END PGP SIGNATURE-
--
Hans
Problems with reiserfs when start OpenAFS 1.2.11-fc1 Segmentation fault with kernel 2.4.22-1.2174.nptl
Hi: Iam compile OpenAFS 1.2.11-fc1 with kernel 2.4.22-1.2174.nptl is OK
problems with reiserfs 3.6 and Fedora Core 1
the problems is when start the client AFS recive the messages:
[EMAIL PROTECTED] modload]# service afs start
Found libafs-2.4.22-1.2174.nptl-i686.o from SymTable... Loading...
Starting AFS services.
/etc/init.d/afs: line 305: 3300 Segmentation fault /usr/vice/etc/afsd
${AFSD_OPTIONS}
[EMAIL PROTECTED] modload]# lsmod
Module Size Used byTainted: PF
libafs-2.4.22-1.2174.nptl-i686 483360 0 (unused)
parport_pc 18756 1 (autoclean)
etc,etc
In log messages:
Starting AFS cache scan...Can't open inode 135536
Unable to handle kernel paging request at virtual address
printing eip:
f093e1b0
*pde = 2067
*pte =
Oops: 0002
libafs-2.4.22-1.2174.nptl-i686 parport_pc lp parport autofs tg3 floppy sg
keybdev hid ehci-hcd usb-uhci usbcore mousedev input i830 agpgart reiserfs
ata_piix
CPU:0
EIP:0060:[]Tainted: PF
EFLAGS: 00010282
EIP is at osi_Panic [libafs-2.4.22-1.2174.nptl-i686] 0x20
(2.4.22-1.2174.nptl)
eax: 0018 ebx: e7bd2580 ecx: 0001 edx: e80d6000
esi: ea666b80 edi: ea666c08 ebp: 0400 esp: e80d7c14
ds: 0068 es: 0068 ss: 0068
Process afsd (pid: 3300, stackpage=e80d7000)
Stack: f095c03c 00021170 c0341640 c0341640 ea666b80 ea666c08 c19b4800
f0948130
f095c03c 00021170 c0341640 c0341640 ef724c10
f0b5b000 0001 f090e52d 00021170 0ce4
0ce4
Call Trace: [] .rodata.str1.1 [libafs-2.4.22-1.2174.nptl-i686]
0xe0c (0xe80d7c14)
[] osi_UFSOpen [libafs-2.4.22-1.2174.nptl-i686] 0x120 (0xe80d7c30)
[] .rodata.str1.1 [libafs-2.4.22-1.2174.nptl-i686] 0xe0c
(0xe80d7c34)
[] afs_InitCacheFile [libafs-2.4.22-1.2174.nptl-i686] 0x10d
(0xe80d7c60)
[] reiserfs_file_operations [reiserfs] 0x0 (0xe80d7c7c)
[] reiserfs_file_operations [reiserfs] 0x0 (0xe80d7c80)
[] afs_InitVolumeInfo [libafs-2.4.22-1.2174.nptl-i686] 0x5b
(0xe80d7c90)
[] afs_syscall_call [libafs-2.4.22-1.2174.nptl-i686] 0x5ce
(0xe80d7cb0)
[] activate_page [kernel] 0xab (0xe80d7ce4)
[] getblk [kernel] 0x59 (0xe80d7d00)
[] bread [kernel] 0x20 (0xe80d7d24)
[] is_tree_node [reiserfs] 0x74 (0xe80d7d40)
[] search_by_key [reiserfs] 0x5b1 (0xe80d7d54)
[] journal_end [reiserfs] 0x27 (0xe80d7d94)
[] reiserfs_dirty_inode [reiserfs] 0x7e (0xe80d7da
[] search_by_entry_key [reiserfs] 0xc8 (0xe80d7dd4)
[] pathrelse [reiserfs] 0x21 (0xe80d7df4)
[] reiserfs_readdir [reiserfs] 0x3c7 (0xe80d7e04)
[] __alloc_pages [kernel] 0x64 (0xe80d7e44)
[] __alloc_pages [kernel] 0x64 (0xe80d7e68)
[] vm_enough_memory [kernel] 0x33 (0xe80d7e84)
[] rb_insert_color [kernel] 0x8f (0xe80d7ea0)
[] do_wp_page [kernel] 0x4d (0xe80d7ebc)
[] handle_mm_fault [kernel] 0xf9 (0xe80d7ee0)
[] do_page_fault [kernel] 0x138 (0xe80d7f0c)
[] afs_syscall [libafs-2.4.22-1.2174.nptl-i686] 0x190 (0xe80d7f40)
[] do_page_fault [kernel] 0x0 (0xe80d7fb0)
[] system_call [kernel] 0x33 (0xe80d7fc0)
Code: c6 05 ff ff ff ff 2a 83 c4 1c c3 9074 26 00 b8 1e bd 95
with kernel 2.4.22-2166 and is the same version OpenAFS working good and
startup client AFS good.
Helpme please.
--- End of Forwarded Message ---
Re: Desktop Filesystem Benchmarks in 2.6.3
Hubert Chan wrote: (only sent to ReiserFS list) "Hans" == Hans Reiser <[EMAIL PROTECTED]> writes: [...] Hans> I think V4 will be our last rewrite from scratch because of our Hans> plugins, and because of how easy we find the code to work on now. What about the on-disk filesystem format? Will Reiser5 and Reiser6 have some sort of backward compatability? Can it all be done using plugins? Yes, Reiser6 semantics will be implemented using additional plugins for directories, etc. -- Hans
Re: Formatted over NTFS
Mike Fedyk wrote: David Nielsen wrote: [ David, please keep this on the list... ] Mike Fedyk wrote: David Nielsen wrote: Hi.. i was installing gentoo the other day, and by mistake did a mkreiserfs /dev/hda1 instred of /dev/hdc1 :( /dev/hda1 was a NTFS file system with a lot of data that i dont wat to lose , is there any way to "unformat" the new reiserfs filesystem i made or any way to just restore the files on the disk ? mkreiserfs doesn't write a lot to the disk, so maybe you can just mount it as ntfs and see what you can recover (unless mkreiserfs wrote over your MBT file...) Try the userspace ntfs tools, or even windows >= NT Ok Now it doesnt matter. I took it out and into another machine temporarily, but.. now the disk doesnt power up(on any of the machines) Its an old disk so... Shit, Shit, Shit... Backup, Backup, Backup.. but thanks anyway. David.
Re: [PATCH] corruption bugs in 2.6 v3
Am Mittwoch, 3. März 2004 21:34 schrieb Chris Mason: > Hello everyone, > > These two patches fix corruption problems I've been hitting on 2.6. > Both bugs are present in the vanilla and suse kernels. Both do NOT fix the "lilo" problem. But mkinitrd works. Thanks, Dieter
Some ReiserFS failure situations and questions
This is on a Debian unstable system running 2.4.25. I copied a filesystem to another partition and deleted the partition the original filesystem was on, all while it was mounted R/W (stupid stupid stupid). Then I ended up with a corrupt copy, as well as a corrupt original filesystem even when the partition was restored. The copy was completely unusable. On the corrupted original, reiserfsck --rebuild-tree gave up on one of the root trees and tried to reconstruct things from the rest. Now, I had previously copied this partition from another disk (and deleted that partition, forgetting its geometry). So, I thought perhaps I could determine where that old partition began so I could retrieve the filesystem from it. First I used parted's partition search feature. That yielded nothing for some reason. Then I made some guesses and ran reiserfsck to check. I told reiserfsck to scan the entire partition, which it did, but for some reason it wasn't able to locate the reiserfs superblock which was still there. (I was certain that I placed the new start-of-partition before the old reiserfs location, and that the space had not been re-used.) So each time it simply suggested to create a new superblock, which was not helpful because it would throw away the old filesystem information when doing so. Would it be a good idea to add an option to debugreiserfs to scan for reiserfs superblocks along an entire disk device and report their LBA location, so that e.g. parted could be used to recreate the partition at that location? In the end, I ended up going with --rebuild-tree on the filesystem I had destroyed. It was only able to recover an estimated 1/10 of the files and directory structure. Everything else went in lost+found if it was recovered at all. Worse, most of the files it "recovered" ended up to be corrupt; executable files with pieces of some other text file in them, or full of zeros, etc. There were also some unexplained phantom files that turned up with names full of garbage (control characters and such). These were difficult to delete, but ones in e.g. /usr/lib would make ldconfig complain and/or crash. I'm curious why this chain of events resulted in such a disaster. (mount filesystem R/W, then delete its partition via parted -> kernel re-reads partition table) I mean, this should normally never happen, but why is a R/W mount with no files currently open (single user mode) corrupted so badly by its partition being deleted while the reiserfs driver is running? Wouldn't hitting the reset button be an even worse thing to do in any case? I still have a dd dump of the corrupted partition and a log of --rebuild-tree can be found at http://dbz.icequake.net/share/fsck.log.gz . If anyone has any ideas what I can do to better recover this partition, I would appreciate it. Previously I had a ReiserFS partition of which the very beginning of the partition was overwritten with garbage. This resulted in a similar disaster. I wonder if there is a better idea to recover a filesystem which has had its beginning overwritten. Or maybe the filesystem trees can be mirrored elsewhere on the disk for better recovery options? Anyway, I am a complete newbie at recovering a trashed ReiserFS, so any general strategy or specific ideas for these two cases would help me greatly. I have another problem with reiserfs that happens occasionally. On reiserfs and only reiserfs partitions, when a crash and journal recovery happens, occasionally two files that were open will have their contents "exchanged". For example, a piece of the text file I was editing ends up in a licq contact file, or an emule download gets a piece of a web page from opera in it. Is this a common problem, and what is the best way to keep it from happening? It is irritating because even though the filesystem is made into a consistent state by the journal recovery, I usually have to do some manual hacking to figure out what happened to program's data that is causing it to misbehave, and something like these things usually turns up. This sort of thing never occurred with ext3, or at least I never noticed it. The stranger thing is that it also happens on files open for read only, not just those open for writing or for R/W. Thanks! -- Ryan Underwood, <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Formatted over NTFS
David Nielsen wrote: [ David, please keep this on the list... ] Mike Fedyk wrote: David Nielsen wrote: Hi.. i was installing gentoo the other day, and by mistake did a mkreiserfs /dev/hda1 instred of /dev/hdc1 :( /dev/hda1 was a NTFS file system with a lot of data that i dont wat to lose , is there any way to "unformat" the new reiserfs filesystem i made or any way to just restore the files on the disk ? mkreiserfs doesn't write a lot to the disk, so maybe you can just mount it as ntfs and see what you can recover (unless mkreiserfs wrote over your MBT file...) Try the userspace ntfs tools, or even windows >= NT
Re: [PATCH] updated data=ordered patch for 2.6.3
Am Mittwoch, 3. März 2004 10:13 schrieb Marc-Christian Petersen: > On Tuesday 02 March 2004 20:53, Dieter Nützel wrote: > > Hi Dieter, > > > > > > I'll try on SuSE 2.6.3-16. > > sorry for my ignorance, but where do you find 2.6.3-_16_? I only find -0 ftp://sunsite.informatik.rwth-aachen.de/pub/Linux/suse/people/kraxel Or the "original site" and its mirrors. Regards, Dieter
Re: Formatted over NTFS
David Nielsen wrote: Hi.. i was installing gentoo the other day, and by mistake did a mkreiserfs /dev/hda1 instred of /dev/hdc1 :( /dev/hda1 was a NTFS file system with a lot of data that i dont wat to lose , is there any way to "unformat" the new reiserfs filesystem i made or any way to just restore the files on the disk ? mkreiserfs doesn't write a lot to the disk, so maybe you can just mount it as ntfs and see what you can recover (unless mkreiserfs wrote over your MBT file...)
Re: Bugs on big endian systems
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Pavel -
Thanks. The good news is that the filesystem wouldn't have panicked
because of the SB_ONDISK_RESERVED_FOR_JOURNAL(s) bug. The bad news is
that it wouldn't have mattered because the filesystem could never have
been mounted anyway due to the journal header version mismatch.
I'm surprised nobody's ever tried to mount a relocated journal enabled
filesystem on a big endian machine.
Hans -
This bug appears in both 2.4 and 2.6 kernels and should be fixed in both.
- -Jeff
Pavel Bartusek wrote:
| Hi list,
|
| The attached patch will fix the bugs which appears only on big endian
| systems in the kernel 2.4.25.
|
| regards
|
|
| Pavel Bartusek
| Software Engineering
|
| SYSGO Real-Time Solutions AG | Embedded and Real-Time Software
| Lise-Meitner-Str.15
| 89081 Ulm, Germany
|
| Voice: +49-731-9533-1295
| FAX: +49-731-94683-10
| www.sysgo.com | www.elinos.com | www.osek.de
|
|
|
|
| --- linux.ori/fs/reiserfs/journal.c Mon Aug 25 13:44:43 2003
| +++ linux/fs/reiserfs/journal.c Wed Mar 3 13:26:23 2004
| @@ -2094,7 +2094,7 @@
|
| /* make sure that journal matches to the super block */
| if (is_reiserfs_jr(rs) &&
| -jh->jh_journal.jp_journal_magic != sb_jp_journal_magic(rs)) {
| +le32_to_cpu (jh->jh_journal.jp_journal_magic) !=
sb_jp_journal_magic(rs)) {
| char jname[ 32 ];
| char fname[ 32 ];
|
| @@ -2102,7 +2102,7 @@
| strcpy( fname, kdevname( p_s_sb->s_dev ) );
| printk("journal-460: journal header magic %x (device %s) does not "
| "match magic found in super block %x (device %s)\n",
| - jh->jh_journal.jp_journal_magic, jname,
| + le32_to_cpu (jh->jh_journal.jp_journal_magic), jname,
| sb_jp_journal_magic(rs), fname);
| brelse (bhjh);
| goto free_and_return;
| --- linux.ori/include/linux/reiserfs_fs.h Mon Aug 25 13:44:44 2003
| +++ linux/include/linux/reiserfs_fs.h Wed Mar 3 13:25:45 2004
| @@ -219,7 +219,7 @@
| #define SB_ONDISK_JOURNAL_DEVICE(s) \
| le32_to_cpu ((SB_ONDISK_JP(s)->jp_journal_dev))
| #define SB_ONDISK_RESERVED_FOR_JOURNAL(s) \
| - le32_to_cpu
((SB_V1_DISK_SUPER_BLOCK(s)->s_reserved_for_journal))
| + le16_to_cpu
((SB_V1_DISK_SUPER_BLOCK(s)->s_reserved_for_journal))
|
| #define is_block_in_log_or_reserved_area(s, block) \
| block >= SB_JOURNAL_1st_RESERVED_BLOCK(s) \
- --
Jeff Mahoney
SuSE Labs
[EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFARk4/LPWxlyuTD7IRAkIZAJ0VR8aYna2n3EK/BfZ2SBwKOe9OPQCfYzDH
c8D4gSwDzr93HivtH2FMx5M=
=Jj1U
-END PGP SIGNATURE-
[PATCH] corruption bugs in 2.6 v3
Hello everyone,
These two patches fix corruption problems I've been hitting on 2.6.
Both bugs are present in the vanilla and suse kernels.
reiserfs-search-restart:
This was originally from [EMAIL PROTECTED], I recently made a small
addition to make sure the expected height was checked after reading in
blocks in search_by_key (this depends on reiserfs-lock-lat from my data
logging directory).
reiserfs-write-sched-bug:
Fixes two schedule related bugs during reiserfs_file_write. One place
in the code assumes that after a schedule, path.pos_in_item will still
be valid even if the item has moved. Since items can split during a
schedule this is incorrect.
The second bug took a little longer to figure out,
reiserfs_prepare_file_region_for_write needs to make sure a stale item
pointer isn't used if search_for_position_by_key doesn't return
POSITION_FOUND.
The most common symptoms of the two bugs is attempts to read beyond the
end of the device, file data corruption and errors like this:
is_tree_node: node level X does not match to the expected one Y
Where X and Y are both valid tree heights (between 1 and 5) and usually
one away from each other.
These reproduced reliably for me by running dbench 20 in a loop for
about 20 minutes on an amd64 box.
Hans, I'd like to submit these along with the other fixes I ported from
2.4 and sent to reiserfs-dev. Any objections?
-chris
fix a bug in reiserfs search_by_key call, where it might not properly detect
a change in tree height during a schedule. Originally from [EMAIL PROTECTED]
Index: linux.t/fs/reiserfs/stree.c
===
--- linux.t.orig/fs/reiserfs/stree.c2004-03-03 14:11:40.984705584 -0500
+++ linux.t/fs/reiserfs/stree.c 2004-03-03 14:12:59.466460675 -0500
@@ -678,7 +678,7 @@
current node, and calculate the next current node(next path element)
for the next iteration of this loop.. */
n_block_number = SB_ROOT_BLOCK (p_s_sb);
-expected_level = SB_TREE_HEIGHT (p_s_sb);
+expected_level = -1;
while ( 1 ) {
#ifdef CONFIG_REISERFS_CHECK
@@ -692,7 +692,6 @@
/* prep path to have another element added to it. */
p_s_last_element = PATH_OFFSET_PELEMENT(p_s_search_path,
++p_s_search_path->path_length);
fs_gen = get_generation (p_s_sb);
- expected_level --;
#ifdef SEARCH_BY_KEY_READA
/* schedule read of right neighbor */
@@ -707,21 +706,26 @@
pathrelse(p_s_search_path);
return IO_ERROR;
}
+ if (expected_level == -1)
+ expected_level = SB_TREE_HEIGHT (p_s_sb);
+ expected_level --;
/* It is possible that schedule occurred. We must check whether the key
to search is still in the tree rooted from the current buffer. If
not then repeat search from the root. */
if ( fs_changed (fs_gen, p_s_sb) &&
-(!B_IS_IN_TREE (p_s_bh) || !key_in_buffer(p_s_search_path, p_s_key,
p_s_sb)) ) {
+ (!B_IS_IN_TREE (p_s_bh) ||
+B_LEVEL(p_s_bh) != expected_level ||
+!key_in_buffer(p_s_search_path, p_s_key, p_s_sb))) {
PROC_INFO_INC( p_s_sb, search_by_key_fs_changed );
- PROC_INFO_INC( p_s_sb, search_by_key_restarted );
+ PROC_INFO_INC( p_s_sb, search_by_key_restarted );
PROC_INFO_INC( p_s_sb, sbk_restarted[ expected_level - 1 ] );
decrement_counters_in_path(p_s_search_path);
/* Get the root block number so that we can repeat the search
- starting from the root. */
+ starting from the root. */
n_block_number = SB_ROOT_BLOCK (p_s_sb);
- expected_level = SB_TREE_HEIGHT (p_s_sb);
+ expected_level = -1;
right_neighbor_of_leaf_node = 0;
/* repeat search from the root */
Index: linux.t/fs/reiserfs/file.c
===
--- linux.t.orig/fs/reiserfs/file.c 2004-03-03 14:16:44.762750907 -0500
+++ linux.t/fs/reiserfs/file.c 2004-03-03 14:16:57.361012562 -0500
@@ -365,7 +365,7 @@
// it means there are no existing in-tree representation for file area
// we are going to overwrite, so there is nothing to scan through for holes.
for ( curr_block = 0, itempos = path.pos_in_item ; curr_block < blocks_to_allocate && res == POSITION_FOUND ; ) {
-
+retry:
if ( itempos >= ih_item_len(ih)/UNFM_P_SIZE ) {
/* We run out of data in this indirect item, let's look for another
one. */
@@ -422,8 +422,8 @@
bh=get_last_bh(&path);
ih=get_ih(&path);
item = get_item(&path);
- // Itempos is still the same
- continue;
+ itempos = path.pos_in_item;
+ goto retry;
}
modifying_this_item = 1;
}
@@ -856,8 +856,12 @@
/* Try to find next item */
res = search_for_position_by_key(inode->i_sb, &key, &path);
/* Abort if no more items */
-
Formatted over NTFS
Hi.. i was installing gentoo the other day, and by mistake did a mkreiserfs /dev/hda1 instred of /dev/hdc1 :( /dev/hda1 was a NTFS file system with a lot of data that i dont wat to lose , is there any way to "unformat" the new reiserfs filesystem i made or any way to just restore the files on the disk ? Regards, The to fast enter pressing. David Nielsen
Re: Desktop Filesystem Benchmarks in 2.6.3
(only sent to ReiserFS list) > "Hans" == Hans Reiser <[EMAIL PROTECTED]> writes: [...] Hans> I think V4 will be our last rewrite from scratch because of our Hans> plugins, and because of how easy we find the code to work on now. What about the on-disk filesystem format? Will Reiser5 and Reiser6 have some sort of backward compatability? Can it all be done using plugins? -- Hubert Chan <[EMAIL PROTECTED]> - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA Key available at wwwkeys.pgp.net. Encrypted e-mail preferred.
