Re: reiser4: mount -o remount,ro / causes error on reboot
Peter wrote: On Sun, 10 Sep 2006 17:01:18 +, Peter wrote: this bug was also reported on gentoo wrt the newer baselayout. Indications are it may be a r4 issue, although no one seems to know why! http://bugs.gentoo.org/show_bug.cgi?id=144093 I have the same problem, segfault on boot if the system was shutdown properly. For me the trouble appeared after upgrading to glibc-2.4, there's no problem at all with glibc-2.3.6. On my system (amd64 platform with 64-bit gentoo installation) it doesn't have anything to do with baselayout, just the glibc.
Re: [PATCH] reiser4: fix readv
Hello
On Friday 15 September 2006 06:24, Andrew Morton wrote:
On Wed, 13 Sep 2006 22:12:54 +0400
Vladimir V. Saveliev [EMAIL PROTECTED] wrote:
Hello, Andrew
reiser4 in 2.6.18-rc6-mm2 has a bug. It can not do readv.
The attached patch fixes it by implementing reiser4' aio_read file
operation.
Unfortunately, it appeared to get a loop which is very similar to the one of
fs/read_write.c:do_loop_readv_writev().
Alternatively, if do_loop_readv_writev were EXPORT_SYMBOL-ed
reiser4' aio_read could use it instead. But, there is a problem with
do_loop_readv_writev EXPORT_SYMBOL-ing:
one if its arguments is io_fn_t, which is declared in fs/read_write.h.
If it is ok to move io_fn_t and do_loop_readv_writev declarations to
include/linux/fs.h and to EXPORT_SYMBOL
do_loop_readv_writev the fix will be smaller. Please, let me know what
would you prefer.
Yes, I'd say that do_loop_readv_writev() is suitable for exporting to
filesystems, and that doing so is preferable to duplicating it.
That'd be two patches, please: one to do the export and one to use it in
reiser4.
I assume there's a good reason why reiser4 cannot use
generic_file_aio_read() or vfs_readv(). Please capture that discussion in
the changelog for the first patch, thanks.
It seems the problem can be fixed a bit simpler. Currently, there is a
difference between read and readv: read calls f_op-read if it is defined,
but readv calls f_op-read if f_op-aio_read is not defined. The latest is a
bit unlogical imho:
wouldn't it be more consistent if readv worked via f_op-read if it is defined?
If we fixed readv (do_readv_writev) that way - reiser4 would not need anything
from its aio_read but generic_file_aio_read.
From: Vladimir Saveliev [EMAIL PROTECTED]
There is some asymmetry between read and readv:
read (vfs_read, namely) calls f_op-read when it is defined,
while readv (do_readv_writev) calls f_op-read when f_op-aio_read is not
defined.
This patch makes do_readv_writev to call do_loop_readv_writev
(which calls f_op-read for each segment of i/o vector) if f_op-read is
defined.
Signed-off-by: Vladimir Saveliev [EMAIL PROTECTED]
diff -puN fs/read_write.c~fix-do_readv_writev fs/read_write.c
--- linux-2.6.18-rc6-mm2/fs/read_write.c~fix-do_readv_writev2006-09-15
17:46:03.0 +0400
+++ linux-2.6.18-rc6-mm2-vs/fs/read_write.c 2006-09-17 23:01:17.0
+0400
@@ -608,7 +608,6 @@ static ssize_t do_readv_writev(int type,
if (ret)
goto out;
- fnv = NULL;
if (type == READ) {
fn = file-f_op-read;
fnv = file-f_op-aio_read;
@@ -617,11 +616,11 @@ static ssize_t do_readv_writev(int type,
fnv = file-f_op-aio_write;
}
- if (fnv)
+ if (fn)
+ ret = do_loop_readv_writev(file, iov, nr_segs, pos, fn);
+ else
ret = do_sync_readv_writev(file, iov, nr_segs, tot_len,
pos, fnv);
- else
- ret = do_loop_readv_writev(file, iov, nr_segs, pos, fn);
out:
if (iov != iovstack)
_
Re: [PATCH] reiser4: fix readv
On Sun, 17 Sep 2006 22:39:07 +0400
Vladimir V. Saveliev [EMAIL PROTECTED] wrote:
Hello
On Friday 15 September 2006 06:24, Andrew Morton wrote:
On Wed, 13 Sep 2006 22:12:54 +0400
Vladimir V. Saveliev [EMAIL PROTECTED] wrote:
Hello, Andrew
reiser4 in 2.6.18-rc6-mm2 has a bug. It can not do readv.
The attached patch fixes it by implementing reiser4' aio_read file
operation.
Unfortunately, it appeared to get a loop which is very similar to the one
of
fs/read_write.c:do_loop_readv_writev().
Alternatively, if do_loop_readv_writev were EXPORT_SYMBOL-ed
reiser4' aio_read could use it instead. But, there is a problem with
do_loop_readv_writev EXPORT_SYMBOL-ing:
one if its arguments is io_fn_t, which is declared in fs/read_write.h.
If it is ok to move io_fn_t and do_loop_readv_writev declarations to
include/linux/fs.h and to EXPORT_SYMBOL
do_loop_readv_writev the fix will be smaller. Please, let me know what
would you prefer.
Yes, I'd say that do_loop_readv_writev() is suitable for exporting to
filesystems, and that doing so is preferable to duplicating it.
That'd be two patches, please: one to do the export and one to use it in
reiser4.
I assume there's a good reason why reiser4 cannot use
generic_file_aio_read() or vfs_readv(). Please capture that discussion in
the changelog for the first patch, thanks.
It seems the problem can be fixed a bit simpler. Currently, there is a
difference between read and readv: read calls f_op-read if it is defined,
but readv calls f_op-read if f_op-aio_read is not defined. The latest is a
bit unlogical imho:
wouldn't it be more consistent if readv worked via f_op-read if it is
defined?
If we fixed readv (do_readv_writev) that way - reiser4 would not need
anything from its aio_read but generic_file_aio_read.
From: Vladimir Saveliev [EMAIL PROTECTED]
There is some asymmetry between read and readv:
read (vfs_read, namely) calls f_op-read when it is defined,
while readv (do_readv_writev) calls f_op-read when f_op-aio_read is not
defined.
This patch makes do_readv_writev to call do_loop_readv_writev
(which calls f_op-read for each segment of i/o vector) if f_op-read is
defined.
Signed-off-by: Vladimir Saveliev [EMAIL PROTECTED]
diff -puN fs/read_write.c~fix-do_readv_writev fs/read_write.c
--- linux-2.6.18-rc6-mm2/fs/read_write.c~fix-do_readv_writev 2006-09-15
17:46:03.0 +0400
+++ linux-2.6.18-rc6-mm2-vs/fs/read_write.c 2006-09-17 23:01:17.0
+0400
@@ -608,7 +608,6 @@ static ssize_t do_readv_writev(int type,
if (ret)
goto out;
- fnv = NULL;
if (type == READ) {
fn = file-f_op-read;
fnv = file-f_op-aio_read;
@@ -617,11 +616,11 @@ static ssize_t do_readv_writev(int type,
fnv = file-f_op-aio_write;
}
- if (fnv)
+ if (fn)
+ ret = do_loop_readv_writev(file, iov, nr_segs, pos, fn);
+ else
ret = do_sync_readv_writev(file, iov, nr_segs, tot_len,
pos, fnv);
- else
- ret = do_loop_readv_writev(file, iov, nr_segs, pos, fn);
out:
if (iov != iovstack)
_
OK, thanks. I'll wait to hear from Badari and Christoph on that.
Re: [PATCH] reiser4: fix readv
btw, please be aware that the post-2.6.17 deadlock fixes which went into generic_file_buffered_write() caused a few problems: a) Significant NFS overwrite performance regression (due to running prepare_write/commit_write) against each writev segment. b) Smaller but significant performance regression for all writev() usages (I expect - haven't measured this yet). c) It's still theoretically deadlockable. I am (slowly) working on addressing these issues - more info later. Basically, we will again need to be able to traverse multiple iovec segments within a single prepare_write/commit_write instance. This will impact your batch_write patch, because that patch somewhat codifies in the function layout the concept that we do one-segment-pre-prepare_write(). So that patch will need significant rework, I suspect. What I'm hoping to be able to do is to simply revert the two deadlock-fix patches (so we go back to the 2.6.17 code) and to remove fault_in_pages_readable() and to simply unlock the page after -prepare_write() and lock it again prior to -commit_write(). But I haven't tried that yet - there's quite a bit of preparatory work needed.
Re: Files 2GB and 3.6 version (after converting from 3.5)
Hello On Saturday 16 September 2006 16:25, Pawel Jagoda wrote: Hello. I've backup my data - one file, which have 4060 MB. Unfortunetly I didn't point out that my destination file system is in old 3.5.x version. And of course I cannot read my data after 2GB (it says: Input/Output Error). I have converted my filesystem into 3.6.x, but still I'm not able to read this file. But if I create new file (for example: dd if=/dev/zero of=/mnt/hda3/some_file bs=1M count=3000), there is no problem to read it. Is it possible, to do something to restore my backup from this file? If yes, then how can I do it? Which kernel did you use? 2.6.14.7
