Re: REISER4 problem,
Hello On Thu, 2006-05-04 at 22:24 +0200, John wrote: Hello, I think I may have found a bug. I'm using reiser4 for my /home directory on a 2.6.15 (ubuntu) patched kernel for reiser4. Yesterday I filled my /home once, then emptied it a little, then filled it again, and so on about 3 or 4 times. I shut it down properly and all seemed ok. Then today when I started it, the partition was completelty messed up. I fixed it with fsck but I had a lot of troubles to get it back working even when fsck said it was ok... I had many different error messages in dmesg, like error input/ouput, inode error, and sd error. If I can help you on anything about this please ask, It would be interesting to take a look at error messages you get from kernel and at reiser4.fsck's output.
Re: REISER4 problem,
John wrote (ao): I think I may have found a bug. I'm using reiser4 for my /home directory on a 2.6.15 (ubuntu) patched kernel for reiser4. Yesterday I filled my /home once, then emptied it a little, then filled it again, and so on about 3 or 4 times. I shut it down properly and all seemed ok. Then today when I started it, the partition was completelty messed up. I fixed it with fsck but I had a lot of troubles to get it back working even when fsck said it was ok... I had many different error messages in dmesg, like error input/ouput, inode error, and sd error. That sounds more like a broken disk than a Reiser4 error. Can you post the error messages from dmesg? With kind regards, Sander -- Humilis IT Services and Solutions http://www.humilis.net
Re: reiser4 problem deleting files / directories
Hello On Fri, 2006-04-28 at 12:16 +1000, Daniel Kasak wrote: Hi all. I just ran out of space while compiling, and went to delete everything in /var/tmp/portage. I get the error: rm: reading directory `/var/tmp/portage/nautilus-2.12.2//work/nautilus-2.12.2/cut-n-paste-code': Input/output error rm: cannot remove directory `/var/tmp/portage/nautilus-2.12.2//work/nautilus-2.12.2': Directory not empty This is with: rm -rf /var/tmp/portage/* Also, I've got the following in my kernel messages: reiser4[emerge(11397)]: extent2tail (fs/reiser4/plugin/file/tail_conversion.c:733)[nikita-2282]: WARNING: Partial conversion of 6903045: 0 of 2: -28 reiser4[emerge(11397)]: release_unix_file (fs/reiser4/plugin/file/file.c:2637)[nikita-3233]: WARNING: Failed to convert in release_unix_file (6903045) reiser4[emerge(11397)]: extent2tail (fs/reiser4/plugin/file/tail_conversion.c:733)[nikita-2282]: WARNING: Partial conversion of 6903078: 0 of 4: -28 reiser4[emerge(11397)]: release_unix_file (fs/reiser4/plugin/file/file.c:2637)[nikita-3233]: WARNING: Failed to convert in release_unix_file (6903078) reiser4[emerge(11397)]: extent2tail (fs/reiser4/plugin/file/tail_conversion.c:733)[nikita-2282]: WARNING: Partial conversion of 6903089: 0 of 3: -28 reiser4[emerge(11397)]: release_unix_file (fs/reiser4/plugin/file/file.c:2637)[nikita-3233]: WARNING: Failed to convert in release_unix_file (6903089) reiser4[emerge(11397)]: extent2tail (fs/reiser4/plugin/file/tail_conversion.c:733)[nikita-2282]: WARNING: Partial conversion of 6903079: 0 of 3: -28 reiser4[emerge(11397)]: release_unix_file (fs/reiser4/plugin/file/file.c:2637)[nikita-3233]: WARNING: Failed to convert in release_unix_file (6903079) reiser4[emerge(11397)]: extent2tail (fs/reiser4/plugin/file/tail_conversion.c:733)[nikita-2282]: WARNING: Partial conversion of 6903062: 0 of 4: -28 reiser4[emerge(11397)]: release_unix_file (fs/reiser4/plugin/file/file.c:2637)[nikita-3233]: WARNING: Failed to convert in release_unix_file (6903062) reiser4[emerge(11397)]: extent2tail (fs/reiser4/plugin/file/tail_conversion.c:733)[nikita-2282]: WARNING: Partial conversion of 6903093: 0 of 3: -28 reiser4[emerge(11397)]: release_unix_file (fs/reiser4/plugin/file/file.c:2637)[nikita-3233]: WARNING: Failed to convert in release_unix_file (6903093) reiser4[emerge(11397)]: extent2tail (fs/reiser4/plugin/file/tail_conversion.c:733)[nikita-2282]: WARNING: Partial conversion of 6903095: 0 of 4: -28 reiser4[emerge(11397)]: release_unix_file (fs/reiser4/plugin/file/file.c:2637)[nikita-3233]: WARNING: Failed to convert in release_unix_file (6903095) reiser4[emerge(11397)]: extent2tail (fs/reiser4/plugin/file/tail_conversion.c:733)[nikita-2282]: WARNING: Partial conversion of 6909813: 0 of 3: -28 reiser4[emerge(11397)]: release_unix_file (fs/reiser4/plugin/file/file.c:2637)[nikita-3233]: WARNING: Failed to convert in release_unix_file (6909813) reiser4[emerge(11397)]: extent2tail (fs/reiser4/plugin/file/tail_conversion.c:733)[nikita-2282]: WARNING: Partial conversion of 6909812: 0 of 4: -28 reiser4[emerge(11397)]: release_unix_file (fs/reiser4/plugin/file/file.c:2637)[nikita-3233]: WARNING: Failed to convert in release_unix_file (6909812) These warning seem to be produced at the point where I ran out of space ( I see the 'emerge' process mentioned ). After rebooting, I no longer get these kernel messages, however I am still unable to delete the nautilus folder. I still get: rm: reading directory `/var/tmp/portage/nautilus-2.12.2//work/nautilus-2.12.2/cut-n-paste-code': Input/output error rm: cannot remove directory `/var/tmp/portage/nautilus-2.12.2//work/nautilus-2.12.2': Directory not empty I'd very much prefer it if I didn't have to run fsck.reiser4 on this partition, as it's the root partition on my laptop, and I've had *bad* experiences with data loss after using fsck.resier4 before. Is this my only option? Are you able to delete other files/directories? If yes, you can probably rename nautilus directory somewhere and forget about it. But, as long as something started to go wrong - you should find possibility to fsck the partition at some time.
Re: reiser4 problem deleting files / directories
Hello On Fri, 2006-04-28 at 17:22 +0200, Michael Weissenbacher wrote: Hi, I just ran out of space while compiling, and went to delete everything in /var/tmp/portage. I get the error: rm: reading directory `/var/tmp/portage/nautilus-2.12.2//work/nautilus-2.12.2/cut-n-paste-code': Input/output error rm: cannot remove directory `/var/tmp/portage/nautilus-2.12.2//work/nautilus-2.12.2': Directory not empty just to confirm, i had the same error. i thought it would be unrelated to the partition filling up but reading your post i do believe otherwise now. in my case i restored my fs from a recent backup. could it really be that a released filesystem (reiser4) cannot handle a partition that's filled up to the max without damaging filesystem structures? can somebody from the reiser4 crew comment on this? some time ago we did such tests and evreything was fine. We will do more similar tests however.
Re: reiser4 problem with pam_mktemp
Thank you, it works!
I've just recompiled kernel and now / mounted on reiser4 with /tmp in
the same filesystem,
and pam_mktemp works without problems.
--
Sergey.
Vladimir V. Saveliev пишет:
Hello
sergey ivanov wrote:
I have not succeeded with integrating reiser4 pam_mktemp.
Would you try the attached patch, please.
From one side I recompiled kernel with reiser4 patches modified to
return ENOTTY for attempt to deal with attributes, as tmpfs does.
Pam_mktemp does not work after this. So I returned to the kernel with
original Namesys' patches.
Then by my apeal pam_mktemp was modified to recognize ENOSYS the same
way it recognizes ENOTTY returned by tmpfs and try to deal without
attributes.
But this also does not help pam_mktemp to work.
So I did the following: rebooted to runlevel 1, and then did
# strace -o su.log -fF su - seriv
Once with /tmp on tmpfs and once with /tmp on reiser4.
And the following catches my attention: while on tmpfs, the lines
dealing with attributes looks like the following:
---
2034 mkdir(/tmp/.private, 0711) = 0
2034 lstat64(/tmp/.private, {st_mode=S_IFDIR|0711, st_size=40,
...}) = 0
2034 open(/tmp/.private, O_RDONLY) = 3
2034 ioctl(3, EXT2_IOC_GETFLAGS, 0xbfb7aab8) = -1 ENOTTY (Inappropriate
ioctl for device)
2034 close(3) = 0
2034 mkdir(/tmp/.private/seriv, 01700) = 0
2034 open(/tmp/.private/seriv, O_RDONLY) = 3
2034 ioctl(3, EXT2_IOC_GETFLAGS, 0xbfb7aa88) = -1 ENOTTY (Inappropriate
ioctl for device)
2034 close(3) = 0
2034 chown32(/tmp/.private/seriv, 0, 500) = 0
2034 chmod(/tmp/.private/seriv, 01770) = 0
---
But with /tmp on reiser4, they are:
---
1993 mkdir(/tmp/.private, 0711) = -1 EEXIST (File exists)
1993 lstat64(/tmp/.private, {st_mode=S_IFDIR|0711, st_size=7,
...}) = 0
1993 open(/tmp/.private, O_RDONLY) = 3
1993 ioctl(3, EXT2_IOC_GETFLAGS, 0xbf9e37f8) = -1 EISDIR (Is a
directory)
1993 close(3) = 0
1993 mkdir(/tmp/.private/seriv, 01700) = -1 EEXIST (File exists)
1993 open(/tmp/.private/seriv, O_RDONLY) = 3
1993 ioctl(3, EXT2_IOC_GETFLAGS, 0xbf9e37c8) = -1 EISDIR (Is a
directory)
1993 close(3) = 0
1993 getuid32()= 0
1993 write(2, Account management:- Cannot make..., 85) = 85
---
So it looks like reiser4 tries to be good and answer to ioctl
getting/setting attributes EEXIST and EISDIR, and not return
error ENOTTY. This is the reason, why pam_mktemp passes the tests
if filesystem support attributes with confidence that reiser4 can do
attributes. I think this was the right decision to return fake
successes at the beginning of reiser4 development, but now I think
reiser4 should behave more strictly and rejects this attribute
setting/getting ioctl by ENOTTY codes.
fs/reiser4/plugin/file/file.c |2 +-
fs/reiser4/plugin/object.c| 17 -
2 files changed, 13 insertions(+), 6 deletions(-)
diff -puN fs/reiser4/plugin/object.c~reiser4-pam_mktemp-fix
fs/reiser4/plugin/object.c
--- linux-2.6.13-rc5-mm1/fs/reiser4/plugin/object.c~reiser4-pam_mktemp-fix
2005-08-12 13:42:05.904058842 +0400
+++ linux-2.6.13-rc5-mm1-vs/fs/reiser4/plugin/object.c 2005-08-12
13:46:12.622408259 +0400
@@ -966,6 +966,13 @@ isdir(void)
#define eisdir ((void *)isdir)
+static int
+notty(void)
+{
+ return RETERR(-ENOTTY);
+}
+#define enotty ((void *)notty)
+
static ssize_t
perm(void)
{
@@ -1243,7 +1250,7 @@ file_plugin file_plugins[LAST_FILE_PLUGI
.read = eisdir,
.write = eisdir,
.release = release_dir,
- .ioctl = eisdir,
+ .ioctl = enotty,
.mmap = eisdir,
.get_block = NULL,
.flow_by_inode = NULL,
@@ -1299,7 +1306,7 @@ file_plugin file_plugins[LAST_FILE_PLUGI
.read = eperm,
.write = eperm,
.release = NULL,
- .ioctl = eperm,
+ .ioctl = enotty,
.mmap = eperm,
.sync = sync_common,
.get_block = NULL,
@@ -1358,7 +1365,7 @@ file_plugin file_plugins[LAST_FILE_PLUGI
.read = eperm,
.write = eperm,
.release = NULL,
- .ioctl = eperm,
+ .ioctl = enotty,
.mmap = eperm,
.sync = sync_common,
.get_block = NULL,
@@ -1413,7 +1420,7 @@ file_plugin file_plugins[LAST_FILE_PLUGI
.read = read_pseudo,
.write = write_pseudo,
.release = release_pseudo,
- .ioctl = eperm,
+ .ioctl = enotty,
.mmap = eperm,
.sync = sync_common,
.get_block = eperm,
@@ -1470,7 +1477,7 @@
Re: reiser4 problem with pam_mktemp
I have not succeeded with integrating reiser4 pam_mktemp.
From one side I recompiled kernel with reiser4 patches modified to
return ENOTTY for attempt to deal with attributes, as tmpfs does.
Pam_mktemp does not work after this. So I returned to the kernel with
original Namesys' patches.
Then by my apeal pam_mktemp was modified to recognize ENOSYS the same
way it recognizes ENOTTY returned by tmpfs and try to deal without
attributes.
But this also does not help pam_mktemp to work.
So I did the following: rebooted to runlevel 1, and then did
# strace -o su.log -fF su - seriv
Once with /tmp on tmpfs and once with /tmp on reiser4.
And the following catches my attention: while on tmpfs, the lines
dealing with attributes looks like the following:
---
2034 mkdir(/tmp/.private, 0711) = 0
2034 lstat64(/tmp/.private, {st_mode=S_IFDIR|0711, st_size=40, ...}) = 0
2034 open(/tmp/.private, O_RDONLY) = 3
2034 ioctl(3, EXT2_IOC_GETFLAGS, 0xbfb7aab8) = -1 ENOTTY (Inappropriate
ioctl for device)
2034 close(3) = 0
2034 mkdir(/tmp/.private/seriv, 01700) = 0
2034 open(/tmp/.private/seriv, O_RDONLY) = 3
2034 ioctl(3, EXT2_IOC_GETFLAGS, 0xbfb7aa88) = -1 ENOTTY (Inappropriate
ioctl for device)
2034 close(3) = 0
2034 chown32(/tmp/.private/seriv, 0, 500) = 0
2034 chmod(/tmp/.private/seriv, 01770) = 0
---
But with /tmp on reiser4, they are:
---
1993 mkdir(/tmp/.private, 0711) = -1 EEXIST (File exists)
1993 lstat64(/tmp/.private, {st_mode=S_IFDIR|0711, st_size=7, ...}) = 0
1993 open(/tmp/.private, O_RDONLY) = 3
1993 ioctl(3, EXT2_IOC_GETFLAGS, 0xbf9e37f8) = -1 EISDIR (Is a directory)
1993 close(3) = 0
1993 mkdir(/tmp/.private/seriv, 01700) = -1 EEXIST (File exists)
1993 open(/tmp/.private/seriv, O_RDONLY) = 3
1993 ioctl(3, EXT2_IOC_GETFLAGS, 0xbf9e37c8) = -1 EISDIR (Is a directory)
1993 close(3) = 0
1993 getuid32()= 0
1993 write(2, Account management:- Cannot make..., 85) = 85
---
So it looks like reiser4 tries to be good and answer to ioctl
getting/setting attributes EEXIST and EISDIR,
and not return error ENOTTY.
This is the reason, why pam_mktemp passes the tests if filesystem
support attributes with confidence that reiser4 can do attributes.
I think this was the right decision to return fake successes at the
beginning of reiser4 development, but now I think reiser4 should behave
more strictly and rejects this attribute setting/getting ioctl by ENOTTY
codes.
--
Sergey
Re: reiser4 problem with pam_mktemp
On 8/11/05, sergey ivanov [EMAIL PROTECTED] wrote:
I have not succeeded with integrating reiser4 pam_mktemp.
From one side I recompiled kernel with reiser4 patches modified to
return ENOTTY for attempt to deal with attributes, as tmpfs does.
Pam_mktemp does not work after this. So I returned to the kernel with
original Namesys' patches.
# strace -o su.log -fF su - seriv
1993 mkdir(/tmp/.private, 0711) = -1 EEXIST (File exists)
1993 lstat64(/tmp/.private, {st_mode=S_IFDIR|0711, st_size=7, ...}) = 0
1993 open(/tmp/.private, O_RDONLY) = 3
1993 ioctl(3, EXT2_IOC_GETFLAGS, 0xbf9e37f8) = -1 EISDIR (Is a directory)
So it looks like reiser4 tries to be good and answer to ioctl
getting/setting attributes EEXIST and EISDIR,
and not return error ENOTTY.
This seems kind of confusing -- the problem with the idea that all
files are files and directories... do we really want to be returning
that it's a directory here? My guess is that this is the confusing
bit about this filesystem. AFAIK, this is probably confusing the PAM
code or whatever. *shrugs*
--
~Mike
- Just my two cents
- No man is an island, and no man is unable.
Re: reiser4 problem with pam_mktemp
Hi Vladimir, pam_mktemp can work on filesystem which does not support ext2's file attributes. For example, it works well on tmpfs. For pam_mktemp to recognize the case and work without attributes, the filesystem should return 'ENOTTY' (Inappropriate ioctl for device) as a result of an setting/getting attributes call, as it tmpfs does. But reiser4 returns 'ENOSYS' (Function not implemented). Will you accept patch changing this code to 'ENOTTY'? Sergey Vladimir V. Saveliev wrote: Hello sergey ivanov wrote: I have a problem with reiser4. Recently I have installed Altlinux Compact-rc2 on reiserfs (v3.6), patched kernel 2.6.12 with patch 2.6.12-mm2, created new reiser4 partition hda6 and copied by #cp -ax / /mnt/hda6 there. Fixed /etc/fstab and /boot/grub for new partition and booted. And could not login, with messages in virtual consoles : --- pam_tcb[8386]: login: Authentication passed for root from (uid=0) Login incorrect --- So I rebooted in original on reiserfs 3.6, edited /mnt/hda6/etc/inittab to change one of /sbin/mingetty tty6 to be /bin/bash and after reboot to reiser4 based system saw, that the problem in pam_mktemp, by commenting out string # account required pam_mktemp.so in file /etc/pam.d/system_auth the problem get fixed. Also it get fixed if I create some non-reiser4 partition to place /tmp on it. Thanks for the report. The problem is that reiser4 does not support ext2's file attributes pam_mktemp deals with. Maybe reiser4 should have support for that like reiserfs, but now it does not.
Re: reiser4 problem with pam_mktemp
Hello sergey ivanov wrote: Hi Vladimir, pam_mktemp can work on filesystem which does not support ext2's file attributes. For example, it works well on tmpfs. For pam_mktemp to recognize the case and work without attributes, the filesystem should return 'ENOTTY' (Inappropriate ioctl for device) as a result of an setting/getting attributes call, as it tmpfs does. But reiser4 returns 'ENOSYS' (Function not implemented). Will you accept patch changing this code to 'ENOTTY'? yes Sergey Vladimir V. Saveliev wrote: Hello sergey ivanov wrote: I have a problem with reiser4. Recently I have installed Altlinux Compact-rc2 on reiserfs (v3.6), patched kernel 2.6.12 with patch 2.6.12-mm2, created new reiser4 partition hda6 and copied by #cp -ax / /mnt/hda6 there. Fixed /etc/fstab and /boot/grub for new partition and booted. And could not login, with messages in virtual consoles : --- pam_tcb[8386]: login: Authentication passed for root from (uid=0) Login incorrect --- So I rebooted in original on reiserfs 3.6, edited /mnt/hda6/etc/inittab to change one of /sbin/mingetty tty6 to be /bin/bash and after reboot to reiser4 based system saw, that the problem in pam_mktemp, by commenting out string # account required pam_mktemp.so in file /etc/pam.d/system_auth the problem get fixed. Also it get fixed if I create some non-reiser4 partition to place /tmp on it. Thanks for the report. The problem is that reiser4 does not support ext2's file attributes pam_mktemp deals with. Maybe reiser4 should have support for that like reiserfs, but now it does not.
Re: reiser4 problem with pam_mktemp
Hello sergey ivanov wrote: I have a problem with reiser4. Recently I have installed Altlinux Compact-rc2 on reiserfs (v3.6), patched kernel 2.6.12 with patch 2.6.12-mm2, created new reiser4 partition hda6 and copied by #cp -ax / /mnt/hda6 there. Fixed /etc/fstab and /boot/grub for new partition and booted. And could not login, with messages in virtual consoles : --- pam_tcb[8386]: login: Authentication passed for root from (uid=0) Login incorrect --- So I rebooted in original on reiserfs 3.6, edited /mnt/hda6/etc/inittab to change one of /sbin/mingetty tty6 to be /bin/bash and after reboot to reiser4 based system saw, that the problem in pam_mktemp, by commenting out string # account required pam_mktemp.so in file /etc/pam.d/system_auth the problem get fixed. Also it get fixed if I create some non-reiser4 partition to place /tmp on it. Thanks for the report. The problem is that reiser4 does not support ext2's file attributes pam_mktemp deals with. Maybe reiser4 should have support for that like reiserfs, but now it does not.
