softlink created across different partitions
I'm running SUSE 10.1 with your reiser fs on two partitions. I created a directory, with files, on one partition, but wanted to move that directory and files to another partition, so I did # go to one partition cd /home # try to move directory and files from this partition to another partition mv dot-xyz /root/.xyz The files never moved, and now I've got some sort of soft link existing on the /home partition into the / partition. I can't delete the softlink either. Yes, I can 'rm' the link, but somehow, if I tar into dot-xyz, files end up on /root/.xyz. I've run your latest released fsck and it finds no problems. What are my options?
Re: reiser4 experimental patch
Am Freitag, 10. November 2006 00:39 schrieb [EMAIL PROTECTED]: thanks for answer! :) so, the patch compiles fine (one warning in super_ops.c), the FS boot correctly, but if i execute for exemple startx, kernel panic! i compile reiser4 built in with debug, i will send the error (kernel panic) to the list tomorow because i'm now in my house, and the experinet is on my work computer :) I didn't look closer on your patch, but you shouldn't get a warning in super_ops.c. Which compiler do you use? Can you try the patch, I've made? http://www.stud.tu-ilmenau.de/~johi-in/patch-reiser4-2.6.18.bz2
Re: reiser4 experimental patch
Em Sexta 10 Novembro 2006 09:44, Johannes Hirte escreveu: Am Freitag, 10. November 2006 00:39 schrieb [EMAIL PROTECTED]: thanks for answer! :) so, the patch compiles fine (one warning in super_ops.c), the FS boot correctly, but if i execute for exemple startx, kernel panic! i compile reiser4 built in with debug, i will send the error (kernel panic) to the list tomorow because i'm now in my house, and the experinet is on my work computer :) I didn't look closer on your patch, but you shouldn't get a warning in super_ops.c. Which compiler do you use? Can you try the patch, I've made? http://www.stud.tu-ilmenau.de/~johi-in/patch-reiser4-2.6.18.bz2 Hello, i use gcc 3.4.6 on slamd64 (www.slamd64.com), x86_64. i will try your patch :) i'm on-line now on irc.oftc.net nick smyows #reiser4 and my nootebook is on [EMAIL PROTECTED] ... error from boot today.. reiser4 panicked cowaedly: reiser4[mount(1909)]: check_blocks_bitmap (fs/reiser4/plugin/space/bitmap.c:1268)[zam-623]: assertion failed: reiser4_find_next_zero_bit(bnode_working_data(bnode), end_offset, start_offset) = end_offset Kernel panic - not syncing: reiser4[mount(1909)]: check_blocks_bitmap (fs/reiser4/plugin/space/bitmap.c:1268)[zam-623]: assertion failed: reiser4_find_next_zero_bit(bnode_working_data(bnode), end_offset, start_offset) = end_offset ... yesterday give some error but in /fs/reiser4/context.c line 79 i reboot the computer and works now. i'll compare the super_ops.c :) thaks
Re: reiser4 experimental patch
the diference between my an Johannes Hirte's patch is:
/fs/reiser4/plugins/item/item.h
ssize_t (*write) (struct file *, const char __user *, size_t, loff_t
*pos);
---
int (*write) (struct file *, const char __user *, size_t, loff_t
*pos);
*
/fs/reiser4/super_ops.c
290c290
static int reiser4_statfs(struct dentry *dentry, struct kstatfs *statfs)
---
static int reiser4_statfs(struct super_block *super, struct kstatfs *statfs)
292,293d291
struct super_block *super = dentry-d_sb;
571a570,571
// alterado
575,576c575
void *data,
struct vfsmount *mnt)
---
void *data, struct vfsmount *mnt)
582c581,582
static struct file_system_type reiser4_fs_type = {
---
// alterado
struct file_system_type reiser4_fs_type = {
*
i change my super_ops.c but why you alter te int to ssize_t on item.h?
()'s
Em Sexta 10 Novembro 2006 09:57, Guilherme Covolo escreveu:
Em Sexta 10 Novembro 2006 09:44, Johannes Hirte escreveu:
Am Freitag, 10. November 2006 00:39 schrieb [EMAIL PROTECTED]:
thanks for answer! :)
so, the patch compiles fine (one warning in super_ops.c), the FS boot
correctly, but if i execute for exemple startx, kernel panic! i compile
reiser4 built in with debug, i will send the error (kernel panic) to
the list tomorow because i'm now in my house, and the experinet is on
my work computer :)
I didn't look closer on your patch, but you shouldn't get a warning in
super_ops.c. Which compiler do you use?
Can you try the patch, I've made?
http://www.stud.tu-ilmenau.de/~johi-in/patch-reiser4-2.6.18.bz2
Hello,
i use gcc 3.4.6 on slamd64 (www.slamd64.com), x86_64.
i will try your patch :)
i'm on-line now on irc.oftc.net nick smyows #reiser4 and my nootebook is on
[EMAIL PROTECTED] ...
error from boot today..
reiser4 panicked cowaedly: reiser4[mount(1909)]: check_blocks_bitmap
(fs/reiser4/plugin/space/bitmap.c:1268)[zam-623]: assertion failed:
reiser4_find_next_zero_bit(bnode_working_data(bnode), end_offset,
start_offset) = end_offset
Kernel panic - not syncing: reiser4[mount(1909)]: check_blocks_bitmap
(fs/reiser4/plugin/space/bitmap.c:1268)[zam-623]: assertion failed:
reiser4_find_next_zero_bit(bnode_working_data(bnode), end_offset,
start_offset) = end_offset
...
yesterday give some error but in /fs/reiser4/context.c line 79
i reboot the computer and works now.
i'll compare the super_ops.c :)
thaks
reiserfsck with LVM read-only snapshot
I am sure that this question must have been asked before, but I have searched the lists and googled with no success. I have a system that uses Reiser and LVM. I would like to be able to take a snapshot of the system, verify the snapshot is correct, then save the snapshot elsewhere. I take SHA1 checksums of the backed up images so it is important that the snapshot is read-only. My test script is: lvcreate --snapshot -p r --size 128M --name snaptest1 /dev/serverstore/test1 reiserfsck --check -q -y /dev/serverstore/snaptest1 dd if=/dev/serverstore/snaptest1 bs=16M | openssl sha1 copyImageSHA1 dd if=/dev/serverstore/snaptest1 of=copyimage bs=16M In this situation, reiserfsck always fails with error Trans replayed: mountid 10, transid 10, desc 18, len 199, commit 218, next trans offset 201 bwrite: write 4096 bytes returned -1 (block=16, dev=3): Operation not permitted I have tried adding the --no-journal-available option to tell it *not* to replay the journal, but it insists on trying to replay the journal, even though I have told it not to. When it does this, the same error occurs. I understand that Reiser3 is a journalling file system and you would normally replay the journal, but I want to check my read-only copy of the snapshot so that I know it is valid. I don't want to change the snapshot in any way (e.g. such as writing the journal changes to it) so that I know the checksum and image data match. If I take a R/W snapshot then run reiserfsck, it writes changes to the snapshot. Sometimes these changes take time to propagate down to the LVM image. When this happens, the SHA1 checksum may be done on the old data whilst the copy is done using the new data. I don't want to take the SHA1 checksum on the destination of the copy - in the real system, this is a remote machine, and I want the SHA1 checksum done locally to detect any link errors (yes, I am paranoid). Is there any way to get reiserfsck to analyse a read-only LVM snapshot, even if the journal isn't replayed, etc etc? Thanks, Roger
Re: reiser4 experimental patch
On Fri, 10 Nov 2006 10:59:30 -0200, Guilherme Covolo said: the diference between my an Johannes Hirte's patch is: * /fs/reiser4/super_ops.c 290c290 static int reiser4_statfs(struct dentry *dentry, struct kstatfs *statfs) --- static int reiser4_statfs(struct super_block *super, struct kstatfs *statfs diff -c or diff -u please. That way, if some unrelated thing moves the lines up or down 1 or 2, it still applies. Also, it's easier to look at a 'diff -u' and understand what's going on, because you get to see 3-4 lines either side of the changed lines. i change my super_ops.c but why you alter te int to ssize_t on item.h? ssize_t isn't an int on some architectures, it's a 'long'. As a result if you reference a 32 bit value where you should use 64, you'll certainly end up with something unexpected (probably an oops). pgp89gE9Ad8ly.pgp Description: PGP signature
Re: reiser4 experimental patch
i change my patch, now is equals of the Johannes Hirte's patch .. only difference is my patch have the comment /* change */ in the source. run on x86_64 fine! :) my patch and the Johannes Hirte's patch is linked in my site, www.youare.not.br thanks to all! Em Sexta 10 Novembro 2006 12:42, [EMAIL PROTECTED] escreveu: On Fri, 10 Nov 2006 10:59:30 -0200, Guilherme Covolo said: the diference between my an Johannes Hirte's patch is: * /fs/reiser4/super_ops.c 290c290 static int reiser4_statfs(struct dentry *dentry, struct kstatfs *statfs) --- static int reiser4_statfs(struct super_block *super, struct kstatfs *statfs diff -c or diff -u please. That way, if some unrelated thing moves the lines up or down 1 or 2, it still applies. Also, it's easier to look at a 'diff -u' and understand what's going on, because you get to see 3-4 lines either side of the changed lines. i change my super_ops.c but why you alter te int to ssize_t on item.h? ssize_t isn't an int on some architectures, it's a 'long'. As a result if you reference a 32 bit value where you should use 64, you'll certainly end up with something unexpected (probably an oops).
RE: reiserfsck with LVM read-only snapshot
Hi David, Thanks for the reply - see my comments below... -Original Message- From: David Masover [mailto:[EMAIL PROTECTED] Sent: 10 November 2006 16:54 To: Roger Lucas Cc: reiserfs-list@namesys.com Subject: Re: reiserfsck with LVM read-only snapshot Roger Lucas wrote: I have tried adding the --no-journal-available option to tell it *not* to replay the journal, but it insists on trying to replay the journal, even though I have told it not to. When it does this, the same error occurs. Is there any way you can force reiserfsck to do this read-only? That's what I would like to know. I don't mind if I have to give reiserfsck somewhere else to write the rebuilt journal to (e.g. a file or similar), but I absolutely do not want it writing *back* to the snapshot. I understand that Reiser3 is a journalling file system and you would normally replay the journal, but I want to check my read-only copy of the snapshot so that I know it is valid. It isn't. By definition, assuming this is a snapshot of a live (mounted) filesystem, it's not really valid -- it's as if you pulled the plug. I can understand why you'd want to do this, but any way you run reiserfsck, it's going to tell you that something's wrong, even if that something is only that it hasn't replayed the journal yet. I understand what you mean. I appreciate that snapshotting a live (i.e. mounted read-write) filesystem will give you just that, a snapshot, and individual files may be in a state of flux such that their contents are invalid or inconsistent. In this situation, however, the disk is mounted read-only so it *shouldn't* be changing. I'm just snapshoting the read-only mounted image because I am paranoid. I don't want to change the snapshot in any way (e.g. such as writing the journal changes to it) so that I know the checksum and image data match. If I take a R/W snapshot then run reiserfsck, it writes changes to the snapshot. I see where you're going with this. I don't use LVM for snapshots, but I do use dm_snapshot sometimes, for exactly this sort of thing -- I have one device I don't want to touch, so I grab a chunk of spare space (my swap partition) to use as a snapshot device, and take a read/write snapshot and mess with that. My original partition is untouched, but I can run fsck.reiser4 on the snapshot, try to recover deleted files, etc. Now, bear with me. I know you want a read-only snapshot. What you want to do is create a read/write snapshot of your read-only snapshot. That way, you can still have your checksum run on the read-only snapshot, and it will match what you expect, but you can also run reiserfsck on the read/write snapshot, and throw it away when you're satisfied. Yep. That's what I would like too, but LVM cannot do snapshots-of-snapshots yet. I don't know the procedure for doing this with LVM, but I may be able to show you how I'd do it directly with dm_snapshot. It's a bit more cumbersome than if reiserfsck cooperated, but you're using a script anyway, so it shouldn't be too bad. Hmmm. I'm not sure about dm_snapshot having not used it before and LVM seems to work pretty well (at least as far as its capabilities allow). I'm open to all suggestions, however. - Roger
RE: reiserfsck with LVM read-only snapshot
Thanks - I'll go digging :-) -Original Message- From: David Masover [mailto:[EMAIL PROTECTED] Sent: 10 November 2006 17:45 To: Roger Lucas Cc: reiserfs-list@namesys.com Subject: Re: reiserfsck with LVM read-only snapshot Roger Lucas wrote: Hmmm. I'm not sure about dm_snapshot having not used it before and LVM seems to work pretty well (at least as far as its capabilities allow). I'm open to all suggestions, however. I'm not sure exactly where to point you to, though. The scary thing about dm_snapshot is that there's so little documentation. No, wait, looks like there is. Check a copy of the kernel source: Documentation/device-mapper/snapshot.txt You should be able to get it to work, even on top of LVM. But, if you're only using LVM for snapshots, you might consider using device-mapper directly instead. Try it out on some loop devices first to get an idea of how it works. You know, little 10 meg files with an ext2 fs, set up with losetup (not mount -o loop), then you can play with dmsetup. As far as I know, any device-mapper device can be created from any block device, period -- dmraid works by creating dm_linear devices to represent the partitions of, say, a dm_stripe device. No performance hit that I can tell. If you need more help with that, let me know.
