Re: [PATCH] reiser4: fix readv
On Sun, Sep 17, 2006 at 10:39:07PM +0400, Vladimir V. Saveliev wrote: 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. This behaviour is historic baggae. readv used to call -readv and fall back to -read when it wasn't available. We now merged -readv into -aio_read and kept that behaviour. I think it makes sense, though - if the filesystem supports vator operations via -aio_read we should use them and not fall back to the manual looping around -read. I'd rather change read to do the same thing as readv so we have consistent behaviour. why does this matter for reiser4?
Re: [PATCH] reiser4: fix readv
Hello On Monday 18 September 2006 16:30, Christoph Hellwig wrote: On Sun, Sep 17, 2006 at 10:39:07PM +0400, Vladimir V. Saveliev wrote: 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. This behaviour is historic baggae. readv used to call -readv and fall back to -read when it wasn't available. We now merged -readv into -aio_read and kept that behaviour. I think it makes sense, though - if the filesystem supports vator operations via -aio_read we should use them and not fall back to the manual looping around -read. I'd rather change read to do the same thing as readv so we have consistent behaviour. Can we put it that way: if a filesystem can use page_cache directly - it has to set f_op-aio_read to generic_file_aio_read and set f_op-read to NULL. If the filesystem wants to try to screw things up a bit - it implements f_op-read and its f_op-read is called by sys_read and sys_readv regardless to whether it has aio_read or not? why does this matter for reiser4? reiser4 reads some files via generic page cache routines. In that case reiser4' read calls do_sync_read. Therefore, it has to define f_op-aio_read. OTOH, there are files for which reiser4' read does not call do_sync_read. In case of readv, f_op-aio_read is called directly (if it is defined), which may result in that reiser4' aio_read is called for files for which reiser4' read would never call do_sync_read. To avoid the problem we have to implement reiser4_aio_read which either calls generic_file_aio_read or does something very similar to do_loop_readv_writev.
Re: [PATCH] reiser4: fix readv
On Mon, Sep 18, 2006 at 05:34:42PM +0400, Vladimir V. Saveliev wrote: Can we put it that way: if a filesystem can use page_cache directly - it has to set f_op-aio_read to generic_file_aio_read and set f_op-read to NULL. If the filesystem wants to try to screw things up a bit - it implements f_op-read and its f_op-read is called by sys_read and sys_readv regardless to whether it has aio_read or not? Not entirely. The idea I had in my mind was the following: - real filesystems should always implement the aio_ methods and must support async and vectored I/O - drivers or simple synthetic filesystems can implement just -read and -write and stay out of all the complexity. In the end I would like to enforce and invariant where a fileesystem or driver implements either the aio_ or normal methods, but we can't do that yet as there are far too many places calling thos directly. Thus we have do_sync_read and do_sync_write that are used as read and write methods for those more complex filesystems. (Anyone's got an idea how to enforce that people never set -read and -write to anything else when they implement the aio methods?) why does this matter for reiser4? reiser4 reads some files via generic page cache routines. In that case reiser4' read calls do_sync_read. Therefore, it has to define f_op-aio_read. OTOH, there are files for which reiser4' read does not call do_sync_read. In case of readv, f_op-aio_read is called directly (if it is defined), which may result in that reiser4' aio_read is called for files for which reiser4' read would never call do_sync_read. To avoid the problem we have to implement reiser4_aio_read which either calls generic_file_aio_read or does something very similar to do_loop_readv_writev. In that case reiserfs should only implement aio_read and aio_write methods and use do_loop_readv_writev which we should export for a beginning. Longer term you should try to implement full blown aio and vector support even for those odd files (or find a way to migrate the pagecache). Do files change from odd to normal while they're instanciated? Otherwise you could just declare to sets of file_operations, once that uses the pagecache and one that doesn't and decide at inode instanciation time which one to use.
Re: reiser4: mount -o remount,ro / causes error on reboot
On Sun, 17 Sep 2006 21:45:29 +0300, Jussi Suutari-Jääskö wrote: 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. The fellow who originally posted the bug does not use r4 nor does he use glibc 2.4. http://bugs.gentoo.org/show_bug.cgi?id=147622 Yet, he has the problem we all are enduring. :( -- Peter + Do not reply to this email, it is a spam trap and not monitored. I can be reached via this list, or via jabber: pete4abw at jabber.org ICQ: 73676357
Re: Files 2GB and 3.6 version (after converting from 3.5)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 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? Unfortunately, if you've removed your backup of the original file, the data is lost. If you still have a copy of the original file, you can remove the copy on the converted file system and replace it. The problem you're running into is that converting a file system to v3.6 from v3.5 allows *new* files to grow beyond the 2 GB limit, but not existing ones. The reason for this is that converting the file system only indicates that it has the ability to use files larger than that, but it doesn't update all the existing files. If you create a new file, it uses the newer metadata format that can describe much larger files. - -Jeff - -- Jeff Mahoney SUSE Labs -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFFDsXvLPWxlyuTD7IRAheZAJ9hIwFztEGNgAu12XWunj42e7SYGACglca3 HQI+nvkGehJxOe9asRZweGg= =NUad -END PGP SIGNATURE-
Re: Files 2GB and 3.6 version (after converting from 3.5)
Hello
On Monday 18 September 2006 01:20, Pawel Jagoda wrote:
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
Please try whether the attached patch helps.
diff -puN fs/reiserfs/inode.c~reiserfs-debug-read fs/reiserfs/inode.c
diff -puN fs/reiserfs/inode.c~reiserfs-read-4gb-files fs/reiserfs/inode.c
--- linux-2.6.14.7/fs/reiserfs/inode.c~reiserfs-read-4gb-files 2006-09-19
01:41:46.0 +0400
+++ linux-2.6.14.7-vs/fs/reiserfs/inode.c 2006-09-19 01:41:46.0
+0400
@@ -206,7 +206,7 @@ static inline void set_block_dev_mapped(
static int file_capable(struct inode *inode, long block)
{
if (get_inode_item_key_version(inode) != KEY_FORMAT_3_5 || // it
is new file.
- block (1 (31 - inode-i_sb-s_blocksize_bits)))// old
file, but 'block' is inside of 2gb
+ block (1 (32 - inode-i_sb-s_blocksize_bits)))// old
file, but 'block' is inside of 2gb
return 1;
return 0;
_
reiser4 resize
Short summary: Will a resize program for reiser4 be available within the next six months? Long explanation: I use a 3ware SATA raid card for the main storage on my home network. I currently have 8 250 GB drives in a raid 5 + hot spare configuration. I chose this card because it allows for online capacity expansion. My plan was to wait until a few generations of hard drives emerged then upgrade them one at a time in cycles. This way my storage will periodically expand without any major downtime. When I first created the filesystem, there was a reiser4 resize program. This is no longer the case. I've began my next upgrade cycle with the purchase of two 750 GB drives. I plan to buy one each month until all eight are replaced. Now I need to make a decision. Do I backup my raid onto the new drives and reformat my raid with another filesystem (xfs, reiser3, jfs), or do I put these new drives into the array and assume that when the time comes to resize the filesystem that a working program will exist?
