Re: EACCESS vs ENOENT for nonexistent files-within-files
From: Joe Orton [EMAIL PROTECTED] Hi, we had a bug report that Apache httpd logs a spurious error for every file served from a reiser4 filesystem, because httpd assumes that /path/to/file/.htaccess (where /path/to/file is a normal file) returns ENOENT or ENOTDIR, but reiser4 returns EACCES in this case. Thank you. I was just tracking down a similar problem with BitKeeper that is explained by this bug. You saved me some work. -Wayne
Re: EACCESS vs ENOENT for nonexistent files-within-files
Hi, we had a bug report that Apache httpd logs a spurious error for every file served from a reiser4 filesystem, because httpd assumes that /path/to/file/.htaccess (where /path/to/file is a normal file) returns ENOENT or ENOTDIR, but reiser4 returns EACCES in this case. Can someone explain the justification behind reiser4's behaviour? httpd's assumption does not seem unreasonable, and EACCES seems to make little sense for this error case. i think the problem would be solved by mounting the partition with the nopseudos option. of course, this is not the long-term solution. regards, michael
Re: EACCESS vs ENOENT for nonexistent files-within-files
On Mon, Sep 13, 2004 at 03:06:37PM +0100, Joe Orton wrote:
Hi, we had a bug report that Apache httpd logs a spurious error for
every file served from a reiser4 filesystem, because httpd assumes that
/path/to/file/.htaccess (where /path/to/file is a normal file) returns
ENOENT or ENOTDIR, but reiser4 returns EACCES in this case.
Can someone explain the justification behind reiser4's behaviour?
httpd's assumption does not seem unreasonable, and EACCES seems to make
little sense for this error case.
It is because open(name, O_DIRECTORY) is successful for regular files in
reiser4. Once it succedes, Apache2 thinks that is a directory and tries to
open .htaccess under it. It does not matter what error code is receives there,
the problem is that apache2 has decided that the file is a directory.
There are two solutions:
1) mount reiser4 partition with nopseudo mount option. it makes /metas/* files
unaccessible.
2) apply the patch:
= fs/namei.c 1.104 vs edited =
--- 1.104/fs/namei.cTue Aug 10 16:59:38 2004
+++ edited/fs/namei.c Sun Sep 12 11:00:18 2004
@@ -816,7 +816,7 @@
break;
if (lookup_flags LOOKUP_DIRECTORY) {
err = -ENOTDIR;
- if (!inode-i_op || !inode-i_op-lookup)
+ if (!S_ISDIR(inode-i_mode))
break;
}
goto return_base;
===
Regards,
joe
--
Alex.
Re: Repacker for reiser4?
Markus Törnqvist wrote:
Is the repacker available for reiser4? I can see code in
it works with echo 1 /sys/fs/reiser4/hda2/repacker/start afaik, but
I haven't tried it myself yet, as my backups are a bit out of date.
Thanks Markus.
As far as I can tell (can anybody confirm/deny), it's up to userspace
to manually toggle the 'direction' flag as required before starting
the repacker - the direction seems to default to 0 ('backward') on each
mount.
It works fine for me on 600Mb of test data which I have heavily
fragmented with a test script.
A 'diff -r' reports no differences with the original data (stored
in ext3), and I can see the tree-frag and data-frag values
falling in measurefs.ext4.
I hope to do some timings over the next few days of how fragmentation
degrades performance of both ext3 and reiser4, given the same
sequence of operations on each filesystem. And then, whether the
repacker fixes things for reiser4. Naturally, ext3 fragmentation
cannot be fixed :)
Will Smith
Re: Repacker for reiser4?
On Tue, Sep 14, 2004 at 01:42:42AM +0800, Will Smith wrote:
As far as I can tell (can anybody confirm/deny), it's up to userspace
to manually toggle the 'direction' flag as required before starting
the repacker - the direction seems to default to 0 ('backward') on each
mount.
Sure seems that way...
sequence of operations on each filesystem. And then, whether the
repacker fixes things for reiser4. Naturally, ext3 fragmentation
cannot be fixed :)
I heard a rumor that ext3's fragmentation is fixed by fsck, can anyone
deny or confirm this?
How do you measure ext3's fragmentation, btw?
(An old reiserfs user asking ;)
--
mjt
Re: EACCESS vs ENOENT for nonexistent files-within-files
On Mon, Sep 13, 2004 at 08:13:26PM +0400, Alex Zarochentsev wrote: On Mon, Sep 13, 2004 at 03:06:37PM +0100, Joe Orton wrote: Hi, we had a bug report that Apache httpd logs a spurious error for every file served from a reiser4 filesystem, because httpd assumes that /path/to/file/.htaccess (where /path/to/file is a normal file) returns ENOENT or ENOTDIR, but reiser4 returns EACCES in this case. Can someone explain the justification behind reiser4's behaviour? httpd's assumption does not seem unreasonable, and EACCES seems to make little sense for this error case. It is because open(name, O_DIRECTORY) is successful for regular files in reiser4. Once it succedes, Apache2 thinks that is a directory and tries to open .htaccess under it. I don't think that has anything to do with it. It's a simple open() without O_DIRECTORY which is failing with EACCES. The reporter confirmed this with the simplest of tests: $ touch newfile.txt $ cat newfile.txt/.htaccess cat: newfile.txt/.htaccess: Permission denied this is the behaviour I'm trying to find the justification for. There are two solutions: 1) mount reiser4 partition with nopseudo mount option. it makes /metas/* files unaccessible. If this is broken by default, our users will continue to complain, so that doesn't really help. 2) apply the patch: OK, does this mean you do consider this a bug in reiser4 which will be fixed in future releases, then? Regards, joe
Re: EACCESS vs ENOENT for nonexistent files-within-files
Joe Orton writes: On Mon, Sep 13, 2004 at 08:13:26PM +0400, Alex Zarochentsev wrote: On Mon, Sep 13, 2004 at 03:06:37PM +0100, Joe Orton wrote: Hi, we had a bug report that Apache httpd logs a spurious error for every file served from a reiser4 filesystem, because httpd assumes that /path/to/file/.htaccess (where /path/to/file is a normal file) returns ENOENT or ENOTDIR, but reiser4 returns EACCES in this case. Can someone explain the justification behind reiser4's behaviour? httpd's assumption does not seem unreasonable, and EACCES seems to make little sense for this error case. It is because open(name, O_DIRECTORY) is successful for regular files in reiser4. Once it succedes, Apache2 thinks that is a directory and tries to open .htaccess under it. I don't think that has anything to do with it. It's a simple open() without O_DIRECTORY which is failing with EACCES. The reporter confirmed this with the simplest of tests: The only reason Apache is trying to access regular/.htaccess is because previous open(regular, O_DIRECTORY) returned success. $ touch newfile.txt $ cat newfile.txt/.htaccess cat: newfile.txt/.htaccess: Permission denied this is the behaviour I'm trying to find the justification for. If newfile.txt has no +x bit set, then justification is obvious: UNIX requires +x bit for lookup, and EACCES is returned when trying to lookup anything in a directory (or, in this case, a regular file) without +x bit: $ mkdir zzz $ chmod a-x zzz $ cat zzz/.htaccess cat: zzz/.htaccess: Permission denied This is how things worked for almost 30 years. If you observe EACCES on the file with +x bit---this is unknown bug and test-case is most welcome. There are two solutions: 1) mount reiser4 partition with nopseudo mount option. it makes /metas/* files unaccessible. If this is broken by default, our users will continue to complain, so that doesn't really help. 2) apply the patch: OK, does this mean you do consider this a bug in reiser4 which will be fixed in future releases, then? Regards, joe Nikita.
Re: EACCESS vs ENOENT for nonexistent files-within-files
On Mon, Sep 13, 2004 at 07:52:55PM +0100, Joe Orton wrote: On Mon, Sep 13, 2004 at 08:13:26PM +0400, Alex Zarochentsev wrote: On Mon, Sep 13, 2004 at 03:06:37PM +0100, Joe Orton wrote: Hi, we had a bug report that Apache httpd logs a spurious error for every file served from a reiser4 filesystem, because httpd assumes that /path/to/file/.htaccess (where /path/to/file is a normal file) returns ENOENT or ENOTDIR, but reiser4 returns EACCES in this case. what does the user get in the browser? Can someone explain the justification behind reiser4's behaviour? httpd's assumption does not seem unreasonable, and EACCES seems to make little sense for this error case. It is because open(name, O_DIRECTORY) is successful for regular files in reiser4. Once it succedes, Apache2 thinks that is a directory and tries to open .htaccess under it. I don't think that has anything to do with it. It's a simple open() without O_DIRECTORY which is failing with EACCES. The reporter confirmed this with the simplest of tests: $ touch newfile.txt $ cat newfile.txt/.htaccess cat: newfile.txt/.htaccess: Permission denied But what is the reason why apache2 looks at regular file/.htaccess ? can you ask the user to add execute permitions (just for test) to the file and see would apache2 work with the file. this is the behaviour I'm trying to find the justification for. There are two solutions: 1) mount reiser4 partition with nopseudo mount option. it makes /metas/* files unaccessible. If this is broken by default, our users will continue to complain, so that doesn't really help. 2) apply the patch: OK, does this mean you do consider this a bug in reiser4 which will be fixed in future releases, then? it requires Linux VFS changes, the changes are being discussed in LKML still. Regards, joe -- Alex.
Re: [PATCH] use S_ISDIR() in link_path_walk() to decide whether the last path component is a directory
viro wrote
On Mon, Sep 13, 2004 at 11:49:22AM +0400, Alex Zarochentsev wrote:
Hi,
This patch does not allow open(name, O_DIRECTORY) to be successful for
non-directories in reiser4. It replaces -i_op-lookup != NULL is dir
check for the last path component by explicit S_ISDIR(-i_mode) check.
Regardless to reiser4, S_ISDIR() looks more clear there.
The only objection here is that right now we are guaranteed that cwd and
root of every task have non-NULL -lookup(). With your patch all we have
is S_ISDIR().
So we either need to check for non-NULL -lookup() before the beginning of
loop in link_path_walk() or split the flag in two. I would rather do the
former...
I'm working on something similar, but with alternate pathname resolution
when the path begins with exactly two slashes. Only pseudocode here because
I do not have access to my box:
In path_lookup()
if (*name == '/') {
if (*(name+1)=='/' *(name+2)==':') {
name+=3;
nd-flags = LOOKUP_SLASHSLASH
if (*name!='/')
goto relative;
}
In link_path_walk()
When LOOKUP_SLASHSLASH, handle names as follows:
If this !S_ISDIR()
next.name Behavior
--
. Same if i_op i_op-lookup, else -ENOTDIR.
.. Same.
...Okay if i_op i_op-lookup, else -ENOTDIR.
otherwise Fails with -ENOENT.
If S_ISDIR()
anySame behavior
I tested the //: flag code and this works (in my limited testing yesterday
with bash and some test programs).
This should limit hybrid file-directories to only one valid subdirectory,
the special metadata directory. Thus, if a new/modified app wants to
create/access metadata, it would do something like the following:
# relative path
cd /test
touch foo.txt
mkdir foo.txt/... # FAILS
mkdir //:foo.txt/...
echo JayRandom //:foo.txt/.../Author
# absolute path
echo blahblah //:/test/foo.txt/.../Title
mkdir testdir
mkdir //:testdir/...
echo no //:testdir/.../VirusScan
Yes, this means that a) ... is removed from the namespace and b) directory
metadata directories are visible to naïve applications/users while those for
files are not. But it does provide metadata-aware apps/users a consistent
way to access this info for both files and directories without resorting to
openat(). Since SuS provides for implementation-specific pathname
resolution when pathnames begin with exactly two slashes this should be
legal(?), if desired.
This doesn't address the issue of active metadata objects such as reiser4
provides e.g. foo.txt/metas/perms. That's a different discussion.
David
[PATCH] ReiserFS v3 I/O error handling
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hey all - One of the most common complaints I've heard about ReiserFS is how graceless it is in handling critical I/O errors. ext[23] can handle I/O errors anywhere, with the results being up to the system admin to determine: continue, go read only, or panic. ReiserFS doesn't offer the admin any such choice, instead panicking on any I/O error in the journal. Attached are four patches, against 2.6.9-rc2: * reiserfs-cleanup-buffer-heads.diff - Cleans up handling of buffer head bitfields - uses the kernel supplied FNS_BUFFER macros instead. * reiserfs-cleanup-sb-journal.diff - Cleans up accessing of the journal structure, prefering ~ to create a temporary variable in functions that access ~ the journal structure non-trivially. Should make 0 difference ~ at compile time. * reiserfs-write-lock.diff - Fixes two missing reiserfs_write_unlock() calls on error paths ~ that are unrelated to the last patch. * reiserfs-io-error-handling.diff - Allows ReiserFS to gracefully handle I/O errors in critical code paths. The admin has the option to go read-only or panic. Since ReiserFS has no option to ignore the use of the journal, ~ the continue method is not enabled. These patches have seen a lot of testing in the SuSE Linux Enterprise Server 9 kernel, and are considered ready for mainline. Hans - please take a look. Resent: Since the namesys.com mail server refuses messages over 40k, I've posted the patches at ftp://ftp.suse.com/pub/people/jeffm/reiserfs/kernel-v2.6/io-error/ - -Jeff - -- Jeff Mahoney SuSE Labs -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBRhsvLPWxlyuTD7IRAqa7AJ9ZJa+HnOGYU7OIouWMu34H2mU0MQCgn0H5 QBdLo95dLiXsQdwojQSHAos= =kPTJ -END PGP SIGNATURE-
Re: [PATCH] use S_ISDIR() in link_path_walk() to decide whether the last path component is a directory
On Mon, Sep 13, 2004 at 04:34:15PM -0500, David Dabbs wrote:
I'm working on something similar, but with alternate pathname resolution
when the path begins with exactly two slashes. Only pseudocode here because
I do not have access to my box:
if (*name == '/') {
if (*(name+1)=='/' *(name+2)==':') {
name+=3;
Pathname resolution is a hell of a fundamental thing and kludges
like that are too ugly to be acceptable. If you can't make that clean
and have to resort to stuffing special cases (read: barfbag of ioctl
magnitude) into the areas that might be unspecified by POSIX, don't do it
at all.
I don't like the amount of handwaving from Hans, but *that* is far
worse. Vetoed.
Re: Still unable to use ReiserFS on PowerPC [Oops]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Paavo Hartikainen wrote: | On PowerPC, I have never got ReiserFS working. It breaks apart when | trying to copy contents to ReiserFS from existing Ext3 filesystem. I | tried this about one year ago (PowerPC 603e, latest Linux 2.4 kernel | back then), and now again (PowerPC 604e, Linux 2.4.27 kernel) with | same results. Paavo - As the original author of the endian safeness patches, this report concerns me. This code has been in the kernel for a few years now, and is considered quite stable. I've tried reproducing on my iBook, and could not. Though, 2.4.27 won't even boot on my dual g4 powermac. Do you always get an Oops in the same path? - -Jeff | Mounting with | | mount /dev/scsi/host1/bus0/target4/lun0/part2 /mnt/ | | It looks like this on dmesg: | | --- | SCSI device sdb: 2134305 512-byte hdwr sectors (1093 MB) | /dev/scsi/host1/bus0/target4/lun0: [mac] p1 p2 p3 | reiserfs: found format 3.6 with standard journal | reiserfs: checking transaction log (device sd(8,18)) ... | for (sd(8,18)) | sd(8,18):Using r5 hash to sort names | --- | | Then I try to copy filesystem contents with | | time nice sudo cp -ax / /mnt/ | | Everything starts as expected, but after 90 seconds this ends up with | segmentation fault. By using dmesg | ksymoops, I managed to extract | this: | | --- | ksymoops 2.4.9 on ppc 2.4.27. Options used | -V (default) | -k /proc/ksyms (default) | -l /proc/modules (default) | -o /lib/modules/2.4.27/ (default) | -m /boot/System.map-2.4.27 (default) | | Warning: You did not tell me where to find symbol information. I will | assume that the log matches the kernel and modules that are running | right now and I'll use the default options above for symbol resolution. | If the current kernel and/or modules do not match the log, you can get | more accurate output by telling me the kernel version and where to find | map, modules, ksyms etc. ksymoops -h explains the options. | | Warning (compare_maps): mismatch on symbol xchg_u32 , ksyms_base says c000b1c4, System.map says c00062b8. Ignoring ksyms_base entry | Oops: kernel access of bad area, sig: 11 | NIP: C90EC0BC XER: LR: C90EC708 SP: C3CDFA70 REGS: c3cdf9c0 TRAP: 0300Not tainted | Using defaults from ksymoops -t elf32-powerpc -a powerpc:common | MSR: 9032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11 | TASK = c3cde000[640] 'cp' Last syscall: 4 | last math c3cde000 last altivec | GPR00: C8844000 C3CDFA70 C3CDE000 7300 0007 C3CDFAD8 8000 0001 | GPR08: 0001 0038 3246 10025914 0001 C3CDFE90 | GPR16: 0001 C3CDFD40 C3CDFC10 0001 0007 | GPR24: 0001 0001 8000 C4354400 C3CDFC10 C3CDFAD8 C8844038 0007 | Call backtrace: | C90EC708 C90ED780 C90F6358 C003BD38 C003C718 C90FACB4 | C002AEE0 C002B540 C003866C C0003C3C 6C696173 10008B8C 100040B4 | 10005704 10003CC4 10005AEC 10003CC4 10005AEC 10003CC4 10005AEC | 100064A4 1000310C 10003ACC 0FE97100 | Warning (Oops_read): Code line not seen, dumping what data is available | | | |NIP; c90ec0bc [reiserfs]scan_bitmap_block+5c/540 = | | |GPR0; c8844000 [advansys].data.end+2b65/6bc5 |GPR1; c3cdfa70 _end+3aae864/85f9e54 |GPR2; c3cde000 _end+3aacdf4/85f9e54 |GPR5; c3cdfad8 _end+3aae8cc/85f9e54 |GPR15; c3cdfe90 _end+3aaec84/85f9e54 |GPR17; c3cdfd40 _end+3aaeb34/85f9e54 |GPR21; c3cdfc10 _end+3aaea04/85f9e54 |GPR27; c4354400 _end+41231f4/85f9e54 |GPR28; c3cdfc10 _end+3aaea04/85f9e54 |GPR29; c3cdfad8 _end+3aae8cc/85f9e54 |GPR30; c8844038 [advansys].data.end+2b9d/6bc5 | | | Trace; Before first symbol | Trace; c90ec708 [reiserfs]scan_bitmap+168/23c | Trace; c90ed780 [reiserfs]reiserfs_allocate_blocknrs+7a8/910 | Trace; c90f6358 [reiserfs]reiserfs_get_block+488/1660 | Trace; c003bd38 __block_prepare_write+1f8/384 | Trace; c003c718 block_prepare_write+34/68 | Trace; c90facb4 [reiserfs]reiserfs_prepare_write+8c/a0 | Trace; c002aee0 do_generic_file_write+244/474 | Trace; c002b540 generic_file_write+1a0/1d4 | Trace; c003866c sys_write+b4/148 | Trace; c0003c3c ret_from_syscall_1+0/b4 | Trace; 6c696173 Before first symbol | Trace; 10008b8c Before first symbol | Trace; 100040b4 Before first symbol | Trace; 10005704 Before first symbol | Trace; 10003cc4 Before first symbol | Trace; 10005aec Before first symbol | Trace; 10003cc4 Before first symbol | Trace; 10005aec Before first symbol | Trace; 10003cc4 Before first symbol | Trace; 10005aec Before first symbol | Trace; 100064a4 Before first symbol | Trace; 1000310c Before first symbol | Trace; 10003acc Before first symbol | Trace; 0fe97100 Before first symbol | Trace; Before first symbol | | | 3 warnings issued. Results may not be reliable. | --- | | Same thing happens when I tried to copy | /usr/src/kernel-source-2.4.27 to empty ReiserFS. Any attempt to | access mounted ReiserFS filesystem will hang after that, and I have to | reboot to get back to
RE: Re: [PATCH] use S_ISDIR() in link_path_walk() to decide whether the last path component is a directory
viro wrote:
if (*name == '/') {
if (*(name+1)=='/' *(name+2)==':') {
name+=3;
Pathname resolution is a hell of a fundamental thing and kludges
like that are too ugly to be acceptable. If you can't make that clean
and have to resort to stuffing special cases (read: barfbag of ioctl
magnitude) into the areas that might be unspecified by POSIX, don't do it
at all.
Even though SuS allows for implementation-specific resolution for pathnames
starting with //? It's kludgy, and I suspected that might be the response,
but I thought I'd float it nonetheless.
I don't like the amount of handwaving from Hans, but *that* is far
worse. Vetoed.
Kludgy, yes, but far worse? At least I bothered to take the SuS into
consideration and took the time to try an approach, however kludgy, that
might work within them.
Bilious or not, thanks for the feedback.
david
vs-8115: get_num_ver: not directory item
i got this warning on my md0 (raid 0, two scsi drives) array. i've never seen it before. reiserfsck 3.6.14 (i know, not the latest) didn't detect any problems. i tried to reproduce it, but i couldn't trigger it. i've never seen this before. i found this, which claims to fix it, but it already applied: http://www.mail-archive.com/[EMAIL PROTECTED]/msg03866.html i'm running 2.6.8 UP x86 on an opteron, highmem enabled, no preempt. nothing fancy. -- Tom Vier [EMAIL PROTECTED] DSA Key ID 0x15741ECE
Re: vs-8115: get_num_ver: not directory item
nothing fancy. i forgot to mention i'm using a 64meg journal. -- Tom Vier [EMAIL PROTECTED] DSA Key ID 0x15741ECE
