Re: Filesystem corruption
Hello On Wednesday 30 May 2007 17:25, David Masover wrote: On Tuesday 29 May 2007 07:36:13 Toby Thain wrote: but you can't mention using reiserfs in mixed company without someone accusing you of throwing your data away. People who repeat this rarely have any direct experience of Reiser; they repeat what they've heard; like all myths and legends they are transmitted orally rather than based on scientific observation. Well, there is one problem I vaguely remember that I don't think has been addressed, I think it was one of those lets-put-it-off-till-v4 things. It was the fact that there are a limited number of inodes (or keys, or whatever you call a unique file), and no way of knowing how many you have left until your FS will suddenly, one day refuse to create another file. reiserfs is limited to ~2^32 file creations. It is possible to exhaust but I do not remember any reports about that. (For comparison, ext3 seems to support not only telling you how many inodes you have left, but tuning that on the fly.) But, I haven't run into that, and the only problem I've had lately has been Reiser4 losing data, and crashing occasionally. I switched most of my data off of Reiser4 and onto XFS for that reason. I've also been using ext3 in some places, and Reiser3 in others (one place in particular where space is limited, but I will have tons of small files). I later learned that XFS does out-of-order writes by default, making me think I should give up and invest in UPS hardware. But, switching away from Reiser4 means I no longer see random files (including stuff in, for example, /sbin, that I hadn't touched in months) go up in smoke. Ordinarily I like to help debug things, but not at the risk of my data. Maybe I'll try again later, and see if I can reproduce it in a VM or somewhere safe... that would be great, thanks I do still follow the list, though, in case something interesting happens. It was fun while it lasted!
Re: Filesystem corruption
Hello On Tuesday 29 May 2007 16:36, Toby Thain wrote: I have always found reiser3 to be rock solid My experienced too, over many server years. but you can't mention using reiserfs in mixed company without someone accusing you of throwing your data away. People who repeat this rarely have any direct experience of Reiser; they repeat what they've heard; like all myths and legends they are transmitted orally rather than based on scientific observation. well, there were in past several bad stories when reiserfsck was unable restore filesystems because it was unable to find reiserfs metadata. Later we found that sometimes (for unknown (but not likely due to reiserfs problem) reason) partition table changes so that beginning of a partition gets shifted by few sectors. So, now, when a user reports that reiserfs metadata disappered from a device completely - recovering a partition table to original state makes data available again. You would think the developers would be doing more to counter this but I have been following reiserfs for years and nobody seems to really care all that much. Can't do much about human nature. MySQL suffers from the same baseless poisoned folk wisdom. --Toby
Re: Filesystem corruption
Hello On Tuesday 29 May 2007 08:18, Tracy R Reed wrote: Laurent CARON wrote: Seems to me it is a filesystem corruption. Did I miss it or did not a single person ask you if this happened with reiserfs 3 or 4? Laurent mentioned rebuild-tree mode of reiserfsck. So the problem happened with reiserfs 3. I would be quite surprised if this were reiser 3 and not so surprised if it were reiser 4 which is still beta afaik. Reiser has a nasty reputation for filesystem corruption more than any other fs. I have always found reiser3 to be rock solid but you can't mention using reiserfs in mixed company without someone accusing you of throwing your data away. You would think the developers would be doing more to counter this but I have been following reiserfs for years and nobody seems to really care all that much.
Re: Filesystem corruption
Hello On Monday 28 May 2007 22:16, Laurent CARON wrote: Christian Kujau a écrit : Please try to check the fs with a current version of reiserfsprogs first. As the manpage advises, try --check first and use --rebuild-tree only if you know what you're doing, IOW: have a current backup. Over the past few years, i experienced a few reiser corruption on various hardware (dell, hp, asus, sata, scsi, ide...) with the same symptoms (unredable file/dir). Always ran check which told me to run fix-fixable or rebuild-tree, which I did after ensuring of backup reliability, and the error was corrected (after eventually losing a few files i fortunately had in the backups). Would you run reiserfsck --check -l log and let us see the log? That may give a hint about which kind of corruptions do you have. Also, which kernel/machine is this running on? Do you know *why* this corruption may have occured? Any recent hardware issues? Is ther anything in the logs regarding fs/device errors? Kernel is 2.6.19. The machine does not seem to have any HW issue, nothing strange in the logs. :$ This is just a plain Dell 2650 server with a bunch of SCSI HDD, software raid5 array, reiserfs on top of it. Laurent
Re: Filesystem corruption
Hello On Sunday 27 May 2007 17:18, Laurent CARON wrote: Hi, A few days ago, one of my procmail suddenly receipes stopped to work. I didn't care much since this only was for 1 or 2 mails. Yesterday, i took time to dig it a bit further and looked at the filesystem on my mail server Here is the output of ls -al in the Maildir where my mails are stored total 1341 drwx-- 6 lcaron mail 256 2007-05-24 10:35 ./ drwx-- 363 lcaron mail 12184 2007-05-25 21:52 ../ -rw-r--r-- 1 lcaron mail17 2004-05-25 09:19 courierimapacl drwx-- 2 lcaron mail48 2004-05-25 09:20 courierimapkeywords/ -rw-r--r-- 1 lcaron lcaron 169365 2007-05-24 10:35 courierimapuiddb drwx-- 2 lcaron mail 1185016 2007-05-24 10:26 cur/ -rw--- 1 lcaron mail 0 2004-05-25 09:19 maildirfolder ?- ? ? ??? new drwx-- 2 lcaron mail48 2007-05-24 19:16 tmp/ The entry that scares me is ?- ? ? ??? new Seems to me it is a filesystem corruption. Any other solution than rebuild-tree ? Did you try rm -rf new? Thanks Laurent
Re: Filesystem corruption
Hello On Monday 28 May 2007 18:10, Laurent CARON wrote: Vladimir V. Saveliev a écrit : Did you try rm -rf new? $ rm -rf new rm: cannot lstat `new': Permission denied Is there anything from reiserfs in system logs?
Re: test
On Thursday 24 May 2007 01:07, Edward Shishkin wrote: test lists work
Re: [patch 30/41] reiserfs convert to new aops.
Hello, Nick
On Wednesday 16 May 2007 21:22, Vladimir V. Saveliev wrote:
Two questions - first, is it possible to get rid of reiserfs_prepare_write /
commit_write?
I assume this is not a problem anymore as long as prepare_write and
commit_write of address space operations are NULL now
(with last version of reiserfs-convert-to-new-aops.patch).
Second, can you make use of AOP_FLAG_CONT_EXPAND in order to
get rid of the special generic_cont_expand routine for reiserfs?
Sorry for delay with this. Did you mean something like this?
From: Vladimir Saveliev [EMAIL PROTECTED]
This patch makes reiserfs to use AOP_FLAG_CONT_EXPAND
in order to get rid of the special generic_cont_expand routine
Signed-off-by: Vladimir Saveliev [EMAIL PROTECTED]
diff -puN fs/reiserfs/inode.c~fs-reiserfs-use-generic_cont_expand_simple fs/reiserfs/inode.c
--- linux-2.6.21-mm2/fs/reiserfs/inode.c~fs-reiserfs-use-generic_cont_expand_simple 2007-05-24 02:29:52.0 +0300
+++ linux-2.6.21-mm2-vs/fs/reiserfs/inode.c 2007-05-24 02:34:26.0 +0300
@@ -2561,13 +2561,20 @@ static int reiserfs_write_begin(struct f
int ret;
int old_ref = 0;
+ inode = mapping-host;
+ *fsdata = 0;
+ if (flags AOP_FLAG_CONT_EXPAND
+ (pos (inode-i_sb-s_blocksize - 1)) == 0) {
+ pos ++;
+ *fsdata = (void *)flags;
+ }
+
index = pos PAGE_CACHE_SHIFT;
page = __grab_cache_page(mapping, index);
if (!page)
return -ENOMEM;
*pagep = page;
- inode = mapping-host;
reiserfs_wait_on_write_block(inode-i_sb);
fix_tail_page_for_writing(page);
if (reiserfs_transaction_running(inode-i_sb)) {
@@ -2677,6 +2684,8 @@ static int reiserfs_write_end(struct fil
struct reiserfs_transaction_handle *th;
unsigned start;
+ if ((unsigned)fsdata AOP_FLAG_CONT_EXPAND)
+ pos ++;
reiserfs_wait_on_write_block(inode-i_sb);
if (reiserfs_transaction_running(inode-i_sb))
@@ -3065,7 +3074,7 @@ int reiserfs_setattr(struct dentry *dent
}
/* fill in hole pointers in the expanding truncate case. */
if (attr-ia_size inode-i_size) {
- error = generic_cont_expand(inode, attr-ia_size);
+ error = generic_cont_expand_simple(inode, attr-ia_size);
if (REISERFS_I(inode)-i_prealloc_count 0) {
int err;
struct reiserfs_transaction_handle th;
_
Re: Why reiser does a disk write on every sync() call?
Hello
On Saturday 12 May 2007 17:03, Grzegorz Jaśkiewicz wrote:
sounds like useless waste of time and space
You haven't stated the reason, why it has to create and commit empty
transaction.
I think we should fix that.
Chris, do you think that we could avoid creating fake transactions with the
below patch?
diff -puN fs/reiserfs/super.c~reiserfs-avoid-syncing-clean-fs
fs/reiserfs/super.c
--- linux-2.6.21-mm2/fs/reiserfs/super.c~reiserfs-avoid-syncing-clean-fs
2007-05-16 18:18:45.0 +0300
+++ linux-2.6.21-mm2-vs/fs/reiserfs/super.c 2007-05-16 18:19:06.0
+0300
@@ -62,7 +62,7 @@ static int reiserfs_statfs(struct dentry
static int reiserfs_sync_fs(struct super_block *s, int wait)
{
- if (!(s-s_flags MS_RDONLY)) {
+ if (!(s-s_flags MS_RDONLY) s-s_dirt) {
struct reiserfs_transaction_handle th;
reiserfs_write_lock(s);
if (!journal_begin(th, s, 1))
_
Re: [patch 30/41] reiserfs convert to new aops.
Hello, Nick
This is new version of the patch.
reiserfs_prepare_write and reiserfs_commit_write are still there, but they do
not show themselves in any struct address_space_operations instance.
xattrs and ioctl use them directly.
From: Vladimir Saveliev [EMAIL PROTECTED]
Convert reiserfs to new aops
Signed-off-by: Vladimir Saveliev [EMAIL PROTECTED]
diff -puN fs/reiserfs/inode.c~reiserfs-convert-to-new-aops fs/reiserfs/inode.c
--- linux-2.6.21-mm2/fs/reiserfs/inode.c~reiserfs-convert-to-new-aops 2007-05-16 20:13:36.0 +0300
+++ linux-2.6.21-mm2-vs/fs/reiserfs/inode.c 2007-05-16 20:13:36.0 +0300
@@ -16,11 +16,12 @@
#include linux/mpage.h
#include linux/writeback.h
#include linux/quotaops.h
+#include linux/swap.h
-static int reiserfs_commit_write(struct file *f, struct page *page,
- unsigned from, unsigned to);
-static int reiserfs_prepare_write(struct file *f, struct page *page,
- unsigned from, unsigned to);
+int reiserfs_commit_write(struct file *f, struct page *page,
+ unsigned from, unsigned to);
+int reiserfs_prepare_write(struct file *f, struct page *page,
+ unsigned from, unsigned to);
void reiserfs_delete_inode(struct inode *inode)
{
@@ -2549,8 +2550,71 @@ static int reiserfs_writepage(struct pag
return reiserfs_write_full_page(page, wbc);
}
-static int reiserfs_prepare_write(struct file *f, struct page *page,
- unsigned from, unsigned to)
+static int reiserfs_write_begin(struct file *file,
+struct address_space *mapping,
+loff_t pos, unsigned len, unsigned flags,
+struct page **pagep, void **fsdata)
+{
+ struct inode *inode;
+ struct page *page;
+ pgoff_t index;
+ int ret;
+ int old_ref = 0;
+
+ index = pos PAGE_CACHE_SHIFT;
+ page = __grab_cache_page(mapping, index);
+ if (!page)
+ return -ENOMEM;
+ *pagep = page;
+
+ inode = mapping-host;
+ reiserfs_wait_on_write_block(inode-i_sb);
+ fix_tail_page_for_writing(page);
+ if (reiserfs_transaction_running(inode-i_sb)) {
+ struct reiserfs_transaction_handle *th;
+ th = (struct reiserfs_transaction_handle *)current-
+ journal_info;
+ BUG_ON(!th-t_refcount);
+ BUG_ON(!th-t_trans_id);
+ old_ref = th-t_refcount;
+ th-t_refcount++;
+ }
+ ret = block_write_begin(file, mapping, pos, len, flags, pagep, fsdata,
+reiserfs_get_block);
+ if (ret reiserfs_transaction_running(inode-i_sb)) {
+ struct reiserfs_transaction_handle *th = current-journal_info;
+ /* this gets a little ugly. If reiserfs_get_block returned an
+ * error and left a transacstion running, we've got to close it,
+ * and we've got to free handle if it was a persistent transaction.
+ *
+ * But, if we had nested into an existing transaction, we need
+ * to just drop the ref count on the handle.
+ *
+ * If old_ref == 0, the transaction is from reiserfs_get_block,
+ * and it was a persistent trans. Otherwise, it was nested above.
+ */
+ if (th-t_refcount old_ref) {
+ if (old_ref)
+th-t_refcount--;
+ else {
+int err;
+reiserfs_write_lock(inode-i_sb);
+err = reiserfs_end_persistent_transaction(th);
+reiserfs_write_unlock(inode-i_sb);
+if (err)
+ ret = err;
+ }
+ }
+ }
+ if (ret) {
+ unlock_page(page);
+ page_cache_release(page);
+ }
+ return ret;
+}
+
+int reiserfs_prepare_write(struct file *f, struct page *page,
+ unsigned from, unsigned to)
{
struct inode *inode = page-mapping-host;
int ret;
@@ -2603,8 +2667,101 @@ static sector_t reiserfs_aop_bmap(struct
return generic_block_bmap(as, block, reiserfs_bmap);
}
-static int reiserfs_commit_write(struct file *f, struct page *page,
- unsigned from, unsigned to)
+static int reiserfs_write_end(struct file *file, struct address_space *mapping,
+ loff_t pos, unsigned len, unsigned copied,
+ struct page *page, void *fsdata)
+{
+ struct inode *inode = page-mapping-host;
+ int ret = 0;
+ int update_sd = 0;
+ struct reiserfs_transaction_handle *th;
+ unsigned start;
+
+
+ reiserfs_wait_on_write_block(inode-i_sb);
+ if (reiserfs_transaction_running(inode-i_sb))
+ th = current-journal_info;
+ else
+ th = NULL;
+
+ start = pos (PAGE_CACHE_SIZE - 1);
+ if (unlikely(copied len)) {
+ if (!PageUptodate(page))
+ copied = 0;
+
+ page_zero_new_buffers(page, start + copied, start + len);
+ }
+ flush_dcache_page(page);
+
+ reiserfs_commit_page(inode, page, start, start + copied);
+ unlock_page(page);
+ mark_page_accessed(page);
+ page_cache_release(page);
+
+ /* generic_commit_write does this for us, but does not update the
+ ** transaction tracking stuff when the size changes. So, we have
+ ** to do the i_size updates here.
+ */
+ pos += copied;
+ if (pos inode-i_size) {
+ struct reiserfs_transaction_handle myth;
+ reiserfs_write_lock(inode-i_sb);
+ /* If the file have grown beyond the border where it
+ can have a tail, unmark it as needing a tail
+ packing */
+ if ((have_large_tails(inode-i_sb)
+ inode-i_size i_block_size(inode) * 4)
+ ||
Re: Why reiser does a disk write on every sync() call?
Hello On Monday 26 March 2007 22:12, Lin Shen (lshen) wrote: I'm using iostat to measure disk reads/writes associated with various file operations under Reiser. One thing I noticed and can't explain is that every sync() call by itself (not following a write or anything) will cause an I/O write. Any ideas? The I/O write is performed by reiserfs implementation of sync_fs method of struct super_operations. If filesystem is mounted r/w - reiserfs_sync_fs begins a transaction (or joins an existing one), journal super block if the transaction has zero length, closes the transaction and flushes old transactions including the one which was just closed. So, if there were no transaction to flush before sync() - one transaction of length 1 gets created, closed, committed and flushed. 5 blocks get written to disk in this case. My calculation can be wrong, though. How much I/O do you notice? Lin
Re: Why reiser does a disk write on every sync() call?
Hello On Tuesday 27 March 2007 21:20, Lin Shen (lshen) wrote: I saw 32 blocks by calling sync() alone. iostat used to count sectors which are 512 bytes long. Did you take that into account? Lin -Original Message- From: Vladimir V. Saveliev [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 27, 2007 1:00 AM To: Lin Shen (lshen) Cc: reiserfs-list@namesys.com Subject: Re: Why reiser does a disk write on every sync() call? Hello On Monday 26 March 2007 22:12, Lin Shen (lshen) wrote: I'm using iostat to measure disk reads/writes associated with various file operations under Reiser. One thing I noticed and can't explain is that every sync() call by itself (not following a write or anything) will cause an I/O write. Any ideas? The I/O write is performed by reiserfs implementation of sync_fs method of struct super_operations. If filesystem is mounted r/w - reiserfs_sync_fs begins a transaction (or joins an existing one), journal super block if the transaction has zero length, closes the transaction and flushes old transactions including the one which was just closed. So, if there were no transaction to flush before sync() - one transaction of length 1 gets created, closed, committed and flushed. 5 blocks get written to disk in this case. My calculation can be wrong, though. How much I/O do you notice? Lin
Re: reiserfsck --rebuild-tree failed
Hello On Saturday 10 March 2007 22:56, Vladimir V. Saveliev wrote: Hello On Saturday 10 March 2007 16:00, Sergey Matviyenko wrote: I run reiserfsck --yes --rebuild-tree --scan-whole-partition. With reiserfsprogs-3.6.19 i have error on Pass 3a: lost+found.c 348 pass_3a_look_for_lost look_for_lost: The entry 'lost+found' could not be found in the root directory. there was a patch for this. I will try to find it. Please try ftp://ftp.namesys.com/pub/tmp/reiserfsprogs-3.6.19.tar.gz It fixes something about missing lost+found, so it may work in your case With reiserfsprogs-3.6.19.5 i have error on Pass 2: reiserfsck: ustree.c:51: free_unformatted_nodes: Assertion `to_be_forgotten-b_count 0' failed.
Re: reiserfsck --rebuild-tree failed
Hello On Saturday 10 March 2007 16:00, Sergey Matviyenko wrote: I run reiserfsck --yes --rebuild-tree --scan-whole-partition. With reiserfsprogs-3.6.19 i have error on Pass 3a: lost+found.c 348 pass_3a_look_for_lost look_for_lost: The entry 'lost+found' could not be found in the root directory. there was a patch for this. I will try to find it. With reiserfsprogs-3.6.19.5 i have error on Pass 2: reiserfsck: ustree.c:51: free_unformatted_nodes: Assertion `to_be_forgotten-b_count 0' failed.
Re: Reiser4: Running out of room still causes corruption
Hello On Tuesday 17 October 2006 16:42, Johannes Hirte wrote: Am Dienstag, 10. Oktober 2006 07:48 schrieb Daniel Kasak: Hi all. I'd had more problems with filesystem corruption after running out of space. This could be deletion of partially converted file. I will try to simulate this case. I was able to reproduce this error and log the oops: Thanks Oct 16 01:00:01 Theben cron[22195]: (root) CMD (rm -f /var/spool/cron/lastrun/cron.hourly) Oct 16 01:03:08 Theben reiser4[kio_file(10493)]: extent2tail (fs/reiser4/plugin/file/tail_conversion.c:714)[nikita-2282]: Oct 16 01:03:08 Theben WARNING: Partial conversion of 65795: 3 of 4: -28 Oct 16 01:03:08 Theben reiser4[kio_file(10493)]: release_unix_file (fs/reiser4/plugin/file/file.c:2268)[nikita-3233]: Oct 16 01:03:08 Theben WARNING: Failed (-28) to convert in release_unix_file (65795) Oct 16 01:04:23 Theben Unable to handle kernel NULL pointer dereference at 0048 RIP: Oct 16 01:04:23 Theben [8022e638] truncate_inode_pages_range+0x18/0x2d0 Oct 16 01:04:23 Theben PGD 3f5c1067 PUD 349e5067 PMD 0 Oct 16 01:04:23 Theben Oops: [1] PREEMPT Oct 16 01:04:23 Theben CPU 0 Oct 16 01:04:23 Theben Modules linked in: usblp nvidia sym53c8xx ehci_hcd ohci_hcd uhci_hcd Oct 16 01:04:23 Theben Pid: 24786, comm: konqueror Tainted: P 2.6.18-reiser4 #1 Oct 16 01:04:23 Theben RIP: 0010:[8022e638] [8022e638] truncate_inode_pages_range+0x18/0x2d0 Oct 16 01:04:23 Theben RSP: :8100328f7348 EFLAGS: 00010296 Oct 16 01:04:23 Theben RAX: RBX: 810001585548 RCX: 0001 Oct 16 01:04:23 Theben RDX: 3fff RSI: 3000 RDI: Oct 16 01:04:23 Theben RBP: 81000d2b7440 R08: R09: 81002c41ab38 Oct 16 01:04:23 Theben R10: 0040 R11: 0040 R12: 0003 Oct 16 01:04:23 Theben R13: 0001 R14: R15: Oct 16 01:04:23 Theben FS: 2b530b62f260() GS:807ca000() knlGS:f65f8ba0 Oct 16 01:04:23 Theben CS: 0010 DS: ES: CR0: 8005003b Oct 16 01:04:23 Theben CR2: 0048 CR3: 2e6d5000 CR4: 06e0 Oct 16 01:04:23 Theben Process konqueror (pid: 24786, threadinfo 8100328f6000, task 8100224387e0) Oct 16 01:04:23 Theben Stack: 3000 0003 Oct 16 01:04:23 Theben 000160d2 0046 0046 Oct 16 01:04:23 Theben 81003dcb9090 0292 81003dcb9090 00011210 Oct 16 01:04:23 Theben Call Trace: Oct 16 01:04:23 Theben [803263e8] reiser4_invalidate_pages+0x198/0x240 Oct 16 01:04:23 Theben [8034f0c1] item_body_by_coord_hard+0x11/0x20 Oct 16 01:04:23 Theben [80349ede] extent_size+0x1e/0x60 Oct 16 01:04:23 Theben [80349f94] max_unit_key_extent+0x34/0x60 Oct 16 01:04:23 Theben [8034f096] max_item_key_by_coord+0x36/0x50 Oct 16 01:04:23 Theben [8034a378] kill_hook_extent+0x368/0x490 Oct 16 01:04:23 Theben [8032abe6] reiser4_get_neighbor+0xa6/0x4b0 Oct 16 01:04:23 Theben [8034a010] kill_hook_extent+0x0/0x490 Oct 16 01:04:23 Theben [8033e7e2] call_kill_hooks+0x82/0xa0 Oct 16 01:04:23 Theben [8034f096] max_item_key_by_coord+0x36/0x50 Oct 16 01:04:23 Theben [8033f173] prepare_for_compact+0x4a3/0x7e0 Oct 16 01:04:23 Theben [8033e690] kill_units+0x0/0xa0 Oct 16 01:04:23 Theben [80341060] kill_tail+0x0/0x50 Oct 16 01:04:23 Theben [8033e730] kill_head+0x0/0x30 Oct 16 01:04:23 Theben [803156fd] move_lh_internal+0x13d/0x1a0 Oct 16 01:04:23 Theben [80310470] jload_gfp+0x1c0/0x1f0 Oct 16 01:04:23 Theben [8031245c] lock_carry_node+0x2cc/0x330 Oct 16 01:04:23 Theben [80323f4f] handle_eottl+0x5f/0x790 Oct 16 01:04:23 Theben [8033f5cc] kill_node40+0x3c/0xe0 Oct 16 01:04:23 Theben [803134cd] carry_cut+0x4d/0x60 Oct 16 01:04:23 Theben [80312eea] carry+0xda/0x2b0 Oct 16 01:04:23 Theben [80312594] post_carry+0x54/0xd0 Oct 16 01:04:23 Theben [80317b7f] kill_node_content+0x72f/0x7d0 Oct 16 01:04:23 Theben [80315e8e] longterm_lock_znode+0x3de/0x510 Oct 16 01:04:23 Theben [80325dec] coord_by_handle+0x36c/0x3a0 Oct 16 01:04:23 Theben [80341660] lookup_node40+0x320/0x450 Oct 16 01:04:23 Theben [80310470] jload_gfp+0x1c0/0x1f0 Oct 16 01:04:23 Theben [803185af] cut_tree_worker_common+0x27f/0x370 Oct 16 01:04:23 Theben [8032f0f3] plugin_by_unsafe_id+0x23/0x100 Oct 16 01:04:23 Theben [80318330] cut_tree_worker_common+0x0/0x370 Oct 16 01:04:23 Theben [803164c9] cut_tree_object+0x129/0x220 Oct 16 01:04:23 Theben [8031c01e] znode_make_dirty+0x7e/0xc0 Oct 16 01:04:23 Theben
Re: Fund raising
Hello On Monday 16 October 2006 20:54, Joe Barr wrote: Vladimer, We received a note from Hans' lawyer about an appeal for fund raising, with you given as the contact point for donations. Can you give us more details on this, please? I had no any contacts about this with anybody. William, If I can do anything - please let me know. Btw, can this http://www.namesys.com/support.html be used to collect those donations? Thanks, Joe Barr NewsForge/Linux.com
Re: reiserfs set_page_dirty vs truncate race?
Hello
On Tuesday 10 October 2006 11:44, Nick Piggin wrote:
Hi,
I wonder if resierfs needs to be careful about truncated pages,
I think it is assumed that __set_page_dirty_nobuffers and
__set_page_dirty_buffers care about truncated pages.
or does
your .invalidatepage provide synchronisation against set_page_dirty somehow?
--
Index: linux-2.6/fs/reiserfs/inode.c
===
--- linux-2.6.orig/fs/reiserfs/inode.c
+++ linux-2.6/fs/reiserfs/inode.c
@@ -2840,10 +2840,14 @@ static void reiserfs_invalidatepage(stru
static int reiserfs_set_page_dirty(struct page *page)
{
- struct inode *inode = page-mapping-host;
- if (reiserfs_file_data_log(inode)) {
- SetPageChecked(page);
- return __set_page_dirty_nobuffers(page);
+ struct address_space *mapping = page-mapping;
+ struct inode *inode;
+ if (mapping) {
+ inode = mapping-host;
+ if (reiserfs_file_data_log(inode)) {
+ SetPageChecked(page);
+ return __set_page_dirty_nobuffers(page);
+ }
}
return __set_page_dirty_buffers(page);
}
Re: Problems with --rebuild-tree on network (ENBD) storage
Hello On Friday 06 October 2006 17:10, Bas van Schaik wrote: Hi Vladimir, ok, may I ask you to run badblocks on that device? reiserfsck wants to be able to read and write filesystem device. badblocks will show us whether your device is in good shape. Of course you may ask me this, but I really don't think it's relevant. ReiserFS is on top of (in this specific order) CryptoLoop, LVM, RAID5 and ENBD. If there are bad blocks on one of the 12 (!) disks, then one of my storage servers in the ENBD-cluster would report a bunch of I/O errors, RAID5 would drop the device and ReiserFS won't even notice that a hard drive failed. Furthermore, every RAID5 device has had a resync since the filesystem resize operation, which implies that every bit has been checked at least once. I think the problem lies within the way reiserfsck reads and writes to the underlying block device. Maybe reiserfsck isn't opening the device in direct I/O (O_DIRECT) mode? Yes, it does not. But why would it have to? I think it should, because it's safer, though slower. Maybe O_DIRECT can be set optionally on (or off) using a commandline switch? Maybe O_DIRECT should be used, I do not argue. But there is nothing wrong in not using O_DIRECT. Why would user land application make a computer unusable? reiserfsck uses standard libc's low level i/o functions to read and write a device, it also analyses and modify read data before writing them back. The worst thing reiserfsck can do is 100% CPU consumption. But that also should not hurt a system. I hope you understand what I mean: if user land application makes a box unusable - something is wrong in kernel. I have never dealt with setup like yours. There are so many layers, why there can not be any errors? That's true, of course. But there's (at least) one place in the kernel where userland touches kernel space: buffering. In my case, I think reiserfsck is causing starvation of my TCP buffers, because it doesn't use direct I/O but buffered I/O. Of course, this is a normal (and maybe wise) thing to do when the bottom layer is ATA or SATA (or something like that), but in my case there's a network somewhere between reiserfsck and ATA/SATA. So, I don't expect reiserfsck to use direct I/O by default, but it would be a nice feature for me (and the few others with the same problem?) if direct I/O can be enabled by a commandline switch. I am going to send you a patch to try later today (I hope to complete debugging by that time). Can you dd_rescue your filesystem to a spare device which has less underlaying layers (linear raid or oven plain hard disk) and try reiserfsck --rebuild-tree oin it? I'm sorry, the system is built upon 12 harddrives, with a total of more than 3TB of disk space. I don't have that amount of drives available for creating a backup! Thanks for you thoughts, -- Bas
Re: Problems with --rebuild-tree on network (ENBD) storage
Hello On Thursday 05 October 2006 12:07, you wrote: Hi all, I'm having severe problems with reiserfsck --rebuild-tree on a CryptoLoop over LVM over RAID5 over ENBD (Enhanced Network Block Device) device. The first pass is no problem (finds errors, but runs perfectly), but the second pass hangs my whole system (load increasing to values like 30, 40, 50) after being active for about 20 minutes. Please be precise: which pass hangs? Pass 1 or pass 2? Note that reiserfsck --rebuild-tree starts with pass 0. Please clarify what does hangs whole system mean. If the system hangs so that it has to be hard rebooted - it is very likely that your problem has nothing to do with reiserfsck. If reiserfsck just consumes 100% CPU on pass2 - there is experimental version of reiserfsck which improves pass 2 performance substantially in some cases. Attached, you'll find two graphs of this behaviour. I see nothing attached. We're talking about a cluster of 5 machines, 4 of them are filled with in total about 3TB of harddisks, the 5th one imports those devices using ENBD and performs 4x RAID5 over it. LVM combines those 4 arrays to one device, and the cryptoloop over LVM ensures safe storage. In the normal situation, there should a mount point /backups (from /dev/loop0) with 2.4TB total space. However, about a week ago I added a new RAID-array to LVM, and started resizing my /backups partition to the maximum available space within LVM. During this resize, my new RAID5-array dropped out due to a disk failure (I didn't let md finish syncing the array...) and the resize failed. At that point, I had a corrupt filesystem, and I'm trying to run reiserfsck --rebuild-tree for a week now. I don't know exactly what is happening, but someone hinted me that reiserfsck might be filling up my TCP buffers (remember, it's a networked block device!) which will lock-up all the I/O to the network block device. For your information: I'm running Debian Sarge with a 2.6.17 kernel from Debian Etch and reiserfsprogs version 3.6.19 from Debian Sarge. The 5th system (frontend) contains a P4 3.0GHz and 1GB of RAM. Has anyone seen something like this before? Or does someone have an idea how I can solve this problem? Might it be worth a try to upgrade to Reiser4? If there's no other way, I am willing to give up my data (there's a partial backup of this backup anyway), but I do need to be sure that this won't happen again! BTW, I didn't find out how to subscribe to this list, so please cc. me in your reply! Thanks! Regards, -- Bas van Schaik
Re: is quotacheck slow with reiserfs
Hello On Friday 06 October 2006 00:34, Louis-David Mitterrand wrote: Hello, On a 200-user mail server with a 500gb reiser3 fs, quotacheck takes an hour at boot time. This is a mail server with 200 users. which linux version is in use on the server? Is that normal? Is there a way to speed it up? How do users store their mails? If they store one mail in a separate file, then quotacheck is to iterate over a lot files which can be very time consuming. Thanks,
Re: Problems with --rebuild-tree on network (ENBD) storage
Hello On Friday 06 October 2006 01:59, Bas van Schaik wrote: Hi Vladimir, On Thursday 05 October 2006 12:07, you wrote: Hi all, I'm having severe problems with reiserfsck --rebuild-tree on a CryptoLoop over LVM over RAID5 over ENBD (Enhanced Network Block Device) device. The first pass is no problem (finds errors, but runs perfectly), but the second pass hangs my whole system (load increasing to values like 30, 40, 50) after being active for about 20 minutes. Please be precise: which pass hangs? Pass 1 or pass 2? Note that reiserfsck --rebuild-tree starts with pass 0. I'm sorry: it hangs during the second pass, which is indeed called pass 1. Please clarify what does hangs whole system mean. If the system hangs so that it has to be hard rebooted - Like I said: loads increases dramatically and renders the machine unusable. it is very likely that your problem has nothing to do with reiserfsck. I do think it has something to do with reiserfsck, since the system was functioning fine until I had to repair my filesystem! ok, may I ask you to run badblocks on that device? reiserfsck wants to be able to read and write filesystem device. badblocks will show us whether your device is in good shape. I've tried it for many times now, but it hangs every time during the rebuild-tree. If reiserfsck just consumes 100% CPU on pass2 - there is experimental version of reiserfsck which improves pass 2 performance substantially in some cases. It's not a matter of CPU usage, it's about I/O. I suspect that ReiserFS fills my memory (TCP buffers) faster than they can flush, which causes starvation of the buffers. Attached, you'll find two graphs of this behaviour. I see nothing attached. I think the mailing list doesn't support attachments, but there's not much too see anyway. Just a graph indicating an increasing load. However, thanks for your thoughts! -- Bas We're talking about a cluster of 5 machines, 4 of them are filled with in total about 3TB of harddisks, the 5th one imports those devices using ENBD and performs 4x RAID5 over it. LVM combines those 4 arrays to one device, and the cryptoloop over LVM ensures safe storage. In the normal situation, there should a mount point /backups (from /dev/loop0) with 2.4TB total space. However, about a week ago I added a new RAID-array to LVM, and started resizing my /backups partition to the maximum available space within LVM. During this resize, my new RAID5-array dropped out due to a disk failure (I didn't let md finish syncing the array...) and the resize failed. At that point, I had a corrupt filesystem, and I'm trying to run reiserfsck --rebuild-tree for a week now. I don't know exactly what is happening, but someone hinted me that reiserfsck might be filling up my TCP buffers (remember, it's a networked block device!) which will lock-up all the I/O to the network block device. For your information: I'm running Debian Sarge with a 2.6.17 kernel from Debian Etch and reiserfsprogs version 3.6.19 from Debian Sarge. The 5th system (frontend) contains a P4 3.0GHz and 1GB of RAM. Has anyone seen something like this before? Or does someone have an idea how I can solve this problem? Might it be worth a try to upgrade to Reiser4? If there's no other way, I am willing to give up my data (there's a partial backup of this backup anyway), but I do need to be sure that this won't happen again! BTW, I didn't find out how to subscribe to this list, so please cc. me in your reply! Thanks! Regards, -- Bas van Schaik
Re: partition cannot be mounted from grub
Hello On Thursday 21 September 2006 09:57, Huub wrote: Hi, Using Suse 10.1, I had a spontaneous reboot after which I got a fast running screen full of reiserfs messages. Another (inflicted) reboot and Grub gives error 17, meaning it cannot mount a recognized partition. Using the boot-dvd, I selected Rescue, and logged in as root but I have no idea how to proceed trying to save my system. Help is appreciated. being booted off boot-dvd, please, run reiserfsck for partitions which were formatted as reiserfs and let us see reiserfsck' output. Thanks, Huub
Re: r4 observations
Hello On Wednesday 20 September 2006 22:47, Peter wrote: I booted from a non-reiser4 partition in order to make a backup of my main / which was a r4 partition. After the backup, I unmounted the drive explicitly, then rebooted. I did not use the backed up drive for anything except tar-ring its files. On next boot to the r4 / partition, all kinds of file not found errors occurred. I booted again to my non-r4 partition, and ran fsck.reiser4 --check -y there were fatal errors on my r4 /. The backup was fine. I downgraded back to reiserfs which does not exhibit this problem. I have not experienced any problem with other r4 partitions. Just /. /home, /tmp, /src, etc. are fine. Unfortunately, I don't have time to keep wondering where the problem is or why. Perhaps it's the kernel or the init scripts. Nonetheless, the instability of whatever the problem is is unnerving. Please provide information about which kernel and which reiser4 did you use. Am I correct that you were trying to run gentoo on reiser4?
Re: partition cannot be mounted from grub
Hello On Thursday 21 September 2006 14:19, Huub wrote: being booted off boot-dvd, please, run reiserfsck for partitions which were formatted as reiserfs and let us see reiserfsck' output. fdisk /dev/hdc shows that I have: /dev/hdc1 Linux swap /dev/hdc2 * Linux /dev/hdc3 Linux As I stated in my own response, error 17 means it doesn't recognize a partition as being ReiserFS. Should I do reiserfsck /dev/hdc2 anyway? yes that should give us a hint whether the problem is in reiserfs or in grub
Re: partition cannot be mounted from grub
Hello On Thursday 21 September 2006 16:14, Huub wrote: yes that should give us a hint whether the problem is in reiserfs or in grub Looks like I can do a clean install. If there is no important data on the system - this is the easiest way. No filesystem or superblock found. I would guess that you got partition table corruption. You may want to try to fdisk /dev/hdc in the way it was partitioned before. However, boundaries of partitions are to known presizely for that, though. You may also try gpart(8). It does not look at partition table and may find partition boundaries.
Re: reiser4 resize
Hello On Tuesday 19 September 2006 05:12, Jack Byer wrote: Short summary: Will a resize program for reiser4 be available within the next six months? Currently nobody works on that. So, I guess it is not very likely that reiser4.resize will be created within 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. that was not a working program. 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? I think you should change to a filesystem which has resize.
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: 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;
_
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: v3 rebuild-tree left system in unusable state because of space shortage
Hello On Friday 15 September 2006 12:25, Grzegorz Jaśkiewicz wrote: I had little problem, deleted a 4GB file, but this space was never freed , but file was gone. So I decided to run -check - no problems found, next step was to rebuild tree: [EMAIL PROTECTED]:~# fsck.reiserfs --rebuild-tree -y /dev/hda3 reiserfsck 3.6.19 (2003 www.namesys.com) * ** Do not run the program with --rebuild-tree unless ** ** something is broken and MAKE A BACKUP before using it. ** ** If you have bad sectors on a drive it is usually a bad ** ** idea to continue using it. Then you probably should get ** ** a working hard drive, copy the file system from the bad ** ** drive to the good one -- dd_rescue is a good tool for ** ** that -- and only then run this program. ** ** If you are using the latest reiserfsprogs and it fails ** ** please email bug reports to reiserfs-list@namesys.com, ** ** providing as much information as possible -- your ** ** hardware, kernel, patches, settings, all reiserfsck ** ** messages (including version), the reiserfsck logfile, ** ** check the syslog file for any related information. ** ** If you would like advice on using this program, support ** ** is available for $25 at www.namesys.com/support.html. ** * Will rebuild the filesystem (/dev/hda3) tree Will put log info to 'stdout' Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes Replaying journal.. Reiserfs journal '/dev/hda3' in blocks [18..8211]: 0 transactions replayed ### reiserfsck --rebuild-tree started at Fri Sep 15 09:14:59 2006 ### Pass 0: ### Pass 0 ### Loading on-disk bitmap .. ok, 31232367 blocks marked used Skipping 9164 blocks (super block, journal, bitmaps) 31223203 blocks will be read 0%20%40%60%80%100% left 0, 10725 /sec 383576 directory entries were hashed with r5 hash. r5 hash is selected Flushing..finished Read blocks (but not data blocks) 31223203 Leaves among those 214478 Objectids found 383578 Pass 1 (will try to insert 214478 leaves): ### Pass 1 ### Looking for allocable blocks .. finished 0%20%40%60%80%Not enough allocable blocks, checking bitmap...there are 1 allocable blocks, btw out of disk space Aborted [EMAIL PROTECTED]:~# cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 8 model name : Pentium III (Coppermine) stepping: 6 cpu MHz : 797.453 cache size : 256 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse bogomips: 1581.05 [EMAIL PROTECTED]:~# lspci :00:00.0 Host bridge: Intel Corp. 82815 815 Chipset Host Bridge and Memory Controller Hub (rev 02) :00:02.0 VGA compatible controller: Intel Corp. 82815 CGC [Chipset Graphics Controller] (rev 02) :00:1e.0 PCI bridge: Intel Corp. 82801 PCI Bridge (rev 01) :00:1f.0 ISA bridge: Intel Corp. 82801BA ISA Bridge (LPC) (rev 01) :00:1f.1 IDE interface: Intel Corp. 82801BA IDE U100 (rev 01) :00:1f.4 USB Controller: Intel Corp. 82801BA/BAM USB (Hub #2) (rev 01) :02:08.0 Ethernet controller: Intel Corp. 82801BA/BAM/CA/CAM Ethernet Controller (rev 01) :02:09.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host Controller (rev 80) [EMAIL PROTECTED]:~# dmesg|grep hda [4294673.965000] ide0: BM-DMA at 0x2020-0x2027, BIOS settings: hda:DMA, hdb:pio [4294674.229000] hda: ST3160812A, ATA DISK drive [4294677.878000] hda: max request size: 1024KiB [4294677.921000] hda: 312581808 sectors (160041 MB) w/8192KiB Cache, CHS=19457/255/63, UDMA(100) fsck.reiserfs -V reiserfsck 3.6.19 (2003 www.namesys.com) Linux gj1box 2.6.12-10-386 #1 Thu Sep 14 09:34:39 UTC 2006 i686 GNU/Linux what shall I do? while there is no fix currently for this problem you can solve the problem by expanding underlaying device. One possible solution is to setup a linear array. In the example below I had out of disk space with rebuild-tree /dev/loop0, created 1000 block extention file and losetup-ed it as /dev/loop1, created linear array /dev/md0 of /dev/loop0 and /dev/loop1 and ran reiserfsck --rebuild-sb /dev/md0 to fix number of blocks in the filesystem and reiserfsck --rebuild-tree /dev/md0. 1) dd if=/dev/zero of=ext-1000 count=1000 bs=4096 loseup /dev/loop1 ext-1000 2) create linear raid mdadm -B /dev/md0 --level=linear --raid-devices=2 /dev/loop0 /dev/loop1 3) rebuild super block on /dev/md0 reiserfsck
Re: [PATCH] reiser4: fix readv
Hello On Thursday 14 September 2006 14:35, Peter wrote: On Thu, 14 Sep 2006 11:28:29 +0200, Christian Trefzer wrote: Hi Vladimir, this fixes a bunch of random user space oddities for me. Just patched 2.6.18-rc6-mm2 with this, and some annoyances I could not trace back to a change in user space just went bye-bye. Thanks a lot! Chris This does not patch against 2.6.17-3 patchset however. 2.6.17-3 does not have the problem which that patch fixes. So you do not need it. Any possibility this may be related to some startup issues as noted on other threads here? no. Thx
Re: reiser4: mount -o remount,ro / causes error on reboot
Hello On Wednesday 13 September 2006 01:10, Peter wrote: On Sun, 10 Sep 2006 17:01:18 +, Peter wrote: all snip... To Vladimir and David: This appears to be a nasty gentoo issue. After perusing the forums and bugzilla, it appears that we are not alone in having difficulties with the baselayout. Nonetheless, as the reporter did, I downgraded baselayout from 1.12.4-r7-r7 to 1.11.15-r3 and the reboot problem I noted went away. It is interesting to note that it may be a C program startstop-daemon.c that may be the culprit. I don't expect much help from the gentoo devs since they won't support reiser4, but thought I would throw this out. Sorry to report this as an r4 bug, although it's interesting to note that the 1.12.4 baselayout did NOT cause this problem in reiserfs3.6 I still think that the problem is in reiser4. When the system fails on boot it usually outputs something which may help to understand the problem. Do you see anything like that on faulty startups? You can use either serial or network console to catch kernel output.
[PATCH] reiser4: fix readv
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.
From: Vladimir Saveliev [EMAIL PROTECTED]
This patch adds implementation of aio_read file operation for reiser4.
It is needed because in reiser4 there are files which can not be dealt
with via generic page cache routines.
In case of readv, reiser4 has no meaning to find out file type and to choose
proper
way to read it. As result generic page cache read gets called for files which
can not be
read that way. Reiser4' aio_read method is to fix that problem.
Signed-off-by: Vladimir Saveliev [EMAIL PROTECTED]
diff -puN fs/reiser4/plugin/object.c~reiser4-add-aio_read
fs/reiser4/plugin/object.c
--- linux-2.6.18-rc6-mm2/fs/reiser4/plugin/object.c~reiser4-add-aio_read
2006-09-13 20:18:23.0 +0400
+++ linux-2.6.18-rc6-mm2-vs/fs/reiser4/plugin/object.c 2006-09-13
20:18:23.0 +0400
@@ -101,7 +101,7 @@ file_plugin file_plugins[LAST_FILE_PLUGI
.llseek = generic_file_llseek,
.read = read_unix_file,
.write = do_sync_write,
- .aio_read = generic_file_aio_read,
+ .aio_read = aio_read_unix_file,
.aio_write = generic_file_aio_write,
.ioctl = ioctl_unix_file,
.mmap = mmap_unix_file,
diff -puN fs/reiser4/plugin/file/file.c~reiser4-add-aio_read
fs/reiser4/plugin/file/file.c
--- linux-2.6.18-rc6-mm2/fs/reiser4/plugin/file/file.c~reiser4-add-aio_read
2006-09-13 20:18:23.0 +0400
+++ linux-2.6.18-rc6-mm2-vs/fs/reiser4/plugin/file/file.c 2006-09-13
20:52:30.0 +0400
@@ -2011,6 +2011,54 @@ out:
return result;
}
+/**
+ * aio_read_unix_file - aio_read of struct file_operations
+ * @iocb: i/o control block
+ * @iov: i/o vector
+ * @nr_segs: number of segments in the i/o vector
+ * @pos: file position to read from
+ *
+ * When it is called within reiser4 context (this happens when sys_read is
+ * reading a file built of extents) - just call generic_file_aio_read to
+ * perform read into page cache. When it is called without reiser4 context
+ * (sys_readv) - call read_unix_file for each segments of i/o vector, so that
+ * read_unix_file will be able to choose whether the file is to be read into
+ * page cache or the file is built of tail items and page cache read is not
+ * suitable for it.
+ */
+ssize_t aio_read_unix_file(struct kiocb *iocb, const struct iovec *iov,
+ unsigned long nr_segs, loff_t pos)
+{
+ ssize_t ret = 0;
+
+ if (is_in_reiser4_context())
+ return generic_file_aio_read(iocb, iov, nr_segs, pos);
+
+ while (nr_segs 0) {
+ void __user *base;
+ size_t len;
+ ssize_t nr;
+
+ base = iov-iov_base;
+ len = iov-iov_len;
+ iov++;
+ nr_segs--;
+
+ nr = read_unix_file(iocb-ki_filp, base, len, iocb-ki_pos);
+ if (nr 0) {
+ if (!ret)
+ ret = nr;
+ break;
+ }
+ ret += nr;
+ if (nr != len)
+ break;
+ }
+
+ return ret;
+
+}
+
static ssize_t read_unix_file_container_tails(
struct file *file, char __user *buf, size_t read_amount, loff_t *off)
{
diff -puN fs/reiser4/plugin/file/file.h~reiser4-add-aio_read
fs/reiser4/plugin/file/file.h
--- linux-2.6.18-rc6-mm2/fs/reiser4/plugin/file/file.h~reiser4-add-aio_read
2006-09-13 20:18:23.0 +0400
+++ linux-2.6.18-rc6-mm2-vs/fs/reiser4/plugin/file/file.h 2006-09-13
20:18:23.0 +0400
@@ -15,6 +15,8 @@ int setattr_unix_file(struct dentry *, s
/* file operations */
ssize_t read_unix_file(struct file *, char __user *buf, size_t read_amount,
loff_t *off);
+ssize_t aio_read_unix_file(struct kiocb *, const struct iovec *,
+ unsigned long nr_segs, loff_t pos);
ssize_t write_unix_file(struct file *, const char __user *buf, size_t
write_amount,
loff_t * off);
int ioctl_unix_file(struct inode *, struct file *, unsigned int cmd,
_
Re: reiserfsck (3.6.19) --rebuild-tree failed
Hello On Friday 08 September 2006 13:51, [EMAIL PROTECTED] wrote: Dear all I did a big mistake: - I got bad blocks on my home partition - I created a badblock file using: badblocks -b 4096 -s -v -o /root/hda3.bad /de/hda3 - I tried to use reiserfstune to apply bad blocks: reisefstune -B /root/hda3.bad /dev/hda3 - The tool said I have to use reiserfsck = $ reiserfsck --rebuild-tree --badblocks /root/hda3.bad /dev/hda3 Then I provides Yes after 25% the --rebuild-tree stopped saing that there were bad blocks and that I've to provide the -B option and a badblock file. But this is what I did (using --badblocks /root/hda3.bad). Now /dev/hda3 can't be mounted (rood inode is set to -1). I would be VERY happy if I could mount the partition read only! What can I do? Many Thx in advance Bruno Kernel is 2.6.15 (Debian) reiserfsck -V = 3.6.19 debugreiserfs /dev/hda3: Filesystem state: consistent /home: Reiserfs super block in block 16 on 0x303 of format 3.6 with standard journal Count of blocks on the device: 4883760 Number of bitmaps: 150 Blocksize: 4096 Free blocks (count of blocks - used [journal, bitmaps, data, reserved] blocks): 4883760 Root block: 0 Filesystem is clean Tree height: 65535 Hash function used to sort names: r5 Objectid map size 614, max 972 Journal parameters: Device [0x0] Magic [0x78b2a94e] Size 8193 blocks (including 1 for journal header) (first block 18) Max transaction length 1024 blocks Max batch size 900 blocks Max commit age 30 Blocks reserved by journal: 0 Fs state field: 0x0: sb_version: 2 inode generation number: 500386 UUID: f4fcb46d-04da-43c9-918d-2ef00f8d8412 LABEL: /home Set flags in SB: ATTRIBUTES CLEAN cat /root/hda3.bad 4602176 4602179 4602180 4602181 4602182 4602183 4602185 4602186 4602187 4602188 4602189 4602190 4602191 4602193 4602194 4602195 4602196 4602197 4602198 4602199 4602201 please run for i in `cat /root/hda3.bad`; do debugreiserfs -1 $i /dev/hda3 /dev/null; done and let me see the output
Re: reiserfsck (3.6.19) --rebuild-tree failed
Hello On Friday 08 September 2006 14:51, [EMAIL PROTECTED] wrote: Hi Vladimir please run for i in `cat /root/hda3.bad`; do debugreiserfs -1 $i /dev/hda3 /dev/null; done So many Thx for very fast response. Here's the output: debugreiserfs 3.6.19 (2003 www.namesys.com) 4602176 is used in ondisk bitmap debugreiserfs 3.6.19 (2003 www.namesys.com) 4602179 is used in ondisk bitmap debugreiserfs 3.6.19 (2003 www.namesys.com) 4602180 is used in ondisk bitmap debugreiserfs 3.6.19 (2003 www.namesys.com) 4602181 is used in ondisk bitmap debugreiserfs 3.6.19 (2003 www.namesys.com) 4602182 is used in ondisk bitmap debugreiserfs 3.6.19 (2003 www.namesys.com) 4602183 is used in ondisk bitmap debugreiserfs 3.6.19 (2003 www.namesys.com) 4602185 is used in ondisk bitmap debugreiserfs 3.6.19 (2003 www.namesys.com) 4602186 is used in ondisk bitmap debugreiserfs 3.6.19 (2003 www.namesys.com) 4602187 is used in ondisk bitmap debugreiserfs 3.6.19 (2003 www.namesys.com) 4602188 is used in ondisk bitmap debugreiserfs 3.6.19 (2003 www.namesys.com) 4602189 is used in ondisk bitmap debugreiserfs 3.6.19 (2003 www.namesys.com) 4602190 is used in ondisk bitmap debugreiserfs 3.6.19 (2003 www.namesys.com) 4602191 is used in ondisk bitmap debugreiserfs 3.6.19 (2003 www.namesys.com) 4602193 is used in ondisk bitmap debugreiserfs 3.6.19 (2003 www.namesys.com) 4602194 is used in ondisk bitmap debugreiserfs 3.6.19 (2003 www.namesys.com) 4602195 is used in ondisk bitmap debugreiserfs 3.6.19 (2003 www.namesys.com) 4602196 is used in ondisk bitmap debugreiserfs 3.6.19 (2003 www.namesys.com) 4602197 is used in ondisk bitmap debugreiserfs 3.6.19 (2003 www.namesys.com) 4602198 is used in ondisk bitmap debugreiserfs 3.6.19 (2003 www.namesys.com) 4602199 is used in ondisk bitmap debugreiserfs 3.6.19 (2003 www.namesys.com) 4602201 is used in ondisk bitmap ok, all bad blocks are used. Lets try to find what they are used for: get ftp://ftp.namesys.com/pub/tmp/reiserfsprogs-3.6.19.3.tar.gz and run its debugreiserfs: cat /root/hda3.bad | debugreiserfs -x /dev/hda3
Re: reiserfsck (3.6.19) --rebuild-tree failed
Hello On Friday 08 September 2006 15:30, [EMAIL PROTECTED] wrote: Hi Vladimir ok, all bad blocks are used. Lets try to find what they are used for: cat /root/hda3.bad | debugreiserfs -x /dev/hda3 # cat /root/hda3.bad | ./debugreiserfs -x /dev/hda3 /root/tmp.txt 21 = debugreiserfs 3.6.19.3 (2003 www.namesys.com) list of 21 block numbers is read /0 ah, sorry, I forgot that you ran reiserfsck --rebuild-tree and that did not complete. debureiserfs -x will not help. I will try to reproduce your problem here and debug it. Btw, did reiserfstune say you something like the below? reiserfstune -B list2 /dev/hda2 reiserfstune: Bad block 32793 is used already in reiserfs tree. To mark it as a bad block use reiserfsck --fix-fixable with -B option. block #0 has wrong level 0, has to be 65534 Number of unresolved block numbers: 21 Kind Regards Bruno
Re: reiserfsck (3.6.19) --rebuild-tree failed
Hello On Friday 08 September 2006 16:04, [EMAIL PROTECTED] wrote: Vladimir Btw, did reiserfstune say you something like the below? reiserfstune -B list2 /dev/hda2 reiserfstune: Bad block 32793 is used already in reiserfs tree. To mark it as a bad block use reiserfsck --fix-fixable with -B option. Yes. exactly. Then I did: reiserfsck --rebuild-tree --badblocks /root/hda3.bad /dev/hda3 after 25% the --rebuild-tree stopped saing that there were bad blocks and that I've to provide the -B option and a badblock file. (I thought that -B and --badblocks were the same?) yes I did not use the --fix-fixable option. please run reiserfsck (3.6.19.3) --rebuild-tree --badblocks /root/hda3.bad /dev/hda3 once again and let me see whole output of the command.
Re: Better fsck.reiser4 needed
Hello On Wednesday 06 September 2006 12:01, Joe Feise wrote: Hi, It seems that fsck.reiser4 -a doesn't do anything. It doesn't even detect corruption. I think it is made that way with intention. If fsck.reiser4 -a did corruption detection bootup process would take long time and users would not have the main advantage of journalled filesystems - quick recovering after unclean shutdown. I had a /var corruption (reiser4 on /var) over the weekend, and since I was out of town, the machine was hanging trying to go into multi-user mode I guess here you got reiser4 bug where it hanged trying to access corrupted partition instead of returning -EIO. Was there anything interesting in logs and have you managed to catch them? for a day before I could fix the corruption manually. An fsck that actually would do some automatic repairs (e.g., like ext3 which I use as the root partition) would be really helpful. For now, I have resorted to --fix -y at bootup time for all my reiser4 partitions, but that's just a quick hack, and rather unsatisfactory. Cheers, -Joe
Re: reiser4 corruption on initial copy
hello On Monday 04 September 2006 18:32, Peter wrote: On Fri, 01 Sep 2006 11:02:58 +, Peter wrote: I recently copied over my / partition from a reiserfs to a reiser4 partition. This may be user error, but I wanted to report it anyway. Booting off a live cd- I did the following. snip... I was able to duplicate the problem. Apparently, the Sabayon live cd does not unmount locally mounted partitions. That should not be a problem if sync is called after copy is completed. It looks like Sabayon live cd even does not care to call sync on reboot. Thus, the reiser4 partitions are unclean. When I boot up to the newly created and copied partition, I get the errors I referred to earlier. By manually umounting the partitions I create or copy from -- including /tmp partitions or /var partitions. I do not get the boot time errors.
Re: Reiser FS will not boot after crash
Hello On Tuesday 05 September 2006 04:10, John M Harrison wrote: Hi, You make some good points. I wonder what the right fix is? I certainly think the user should not be stopped from booting and then get the inconsistent filesystem message over and over again as I do. Perhaps GRUB should offer to 'replay' the filesystem after discovering that the filesystem is inconsistent. I am not sure what other choices there are since the kernel and the initial boot filesystem are presumably not loadable? I looked at grub sources. It looks like it takes journal into account. It may have a bug, though. What version of grub do you have? Would you like to help to debug the problem? john On Tue, 5 Sep 2006, Vladimir V. Saveliev wrote: Hello On Tuesday 05 September 2006 00:30, [EMAIL PROTECTED] wrote: On Mon, 04 Sep 2006 23:33:27 +0400, Vladimir V. Saveliev said: after unclean shutdown journal reply is necessary to return reiserfs to consistent state. Maybe GRUB did not do that? A case can be made that GRUB should be keeping its grubby little paws off the filesystem journal. It's a *bootloader*. It's only purpose in life is to load other code that can make intelligent decisions about things like how (or even whether) to replay a filesystem journal. Yes, I did not say that grub has to replay a journal, I just tried to guess why grub failed to boot and why things went ok after fsck.
Re: Need help retrieving data
Hello
On Saturday 02 September 2006 15:26, Alexander Zarochentsev wrote:
On 2 September 2006 13:32, Alex Efros wrote:
Hi!
So, I did everything correctly to fix it? --rebuild-tree doesn't
broke anything?
usually not.
but reiserfsck --rebuild-tree is a complex operation. It has a possibility
to insert wrong blocks into the tree if your fs was used to store another
reiserfs image. and you have a chance to hit new reiserfsck bug.
unfortunately no fix for fsck is available yet.
I think it is not fsck bug. When hash code is unknown - it can be defined on
mount. The attached patch is supposed to fix broken hash detection.
If you provide fixed reiserfsck version, I can run it on my image to
test it and confirm image become mountabe after --rebuild-sb. But I
can't leave this 3GB image on my drive for months, so if you wish
to make the partition mountable again it is enough to change
one byte in the super block from 0 (hash is not set) to 3 (r5 hash).
It can be done by a hex editor.
hexdump -C of block #16 (reiserfs uses 4k-size blocks, numbers start with
0):
...
0030 06 00 01 00 52 65 49 73 45 72 32 46 73 00 00 00
|ReIsEr2Fs...| 0040 03 00 00 00 05 00 c6 04 02 00 00 00 89 28 00
00 |..ф.┴(..| ^^
this byte.
...
according with:
struct reiserfs_super_block_v1 {
...
char s_magic[10]; /* reiserfs magic string indicates that
* file system is reiserfs:
* ReIsErFs or ReIsEr2Fs or ReIsEr3Fs
*/ __le16 s_fs_state; /* it is set to used by fsck to mark which *
phase of rebuilding is done */
__le32 s_hash_function_code;/* indicate, what hash function is
being use ...
this testing from me - please provide fixed version in about 7-10
days or at least notify me when it will be ready - if your need more
time I probably move it to DVD-RW.
I already have a broken fs to experiment with.
diff -puN fs/reiserfs/super.c~reiserfs-fix-fill_super fs/reiserfs/super.c
--- linux-2.6.18-rc4-mm1/fs/reiserfs/super.c~reiserfs-fix-fill_super 2006-09-01 21:13:02.0 +0400
+++ linux-2.6.18-rc4-mm1-vs/fs/reiserfs/super.c 2006-09-03 11:33:12.0 +0400
@@ -1384,7 +1384,7 @@ static __u32 find_hash_out(struct super_
do { // Some serious goto-hater was there ;)
u32 teahash, r5hash, yurahash;
- make_cpu_key(key, inode, ~0, TYPE_DIRENTRY, 3);
+ make_cpu_key(key, inode, LLONG_MAX, TYPE_DIRENTRY, 3);
retval = search_by_entry_key(s, key, path, de);
if (retval == IO_ERROR) {
pathrelse(path);
@@ -1549,7 +1549,7 @@ static int reiserfs_fill_super(struct su
struct reiserfs_super_block *rs;
char *jdev_name;
struct reiserfs_sb_info *sbi;
- int errval = -EINVAL;
+ int errval;
sbi = kmalloc(sizeof(struct reiserfs_sb_info), GFP_KERNEL);
if (!sbi) {
@@ -1576,12 +1576,14 @@ static int reiserfs_fill_super(struct su
if (reiserfs_parse_options
(s, (char *)data, (sbi-s_mount_opt), blocks, jdev_name,
commit_max_age) == 0) {
+ errval = -EINVAL;
goto error;
}
if (blocks) {
SWARN(silent, s, jmacd-7: reiserfs_fill_super: resize option
for remount only);
+ errval = -EINVAL;
goto error;
}
@@ -1593,6 +1595,7 @@ static int reiserfs_fill_super(struct su
SWARN(silent, s,
sh-2021: reiserfs_fill_super: can not find reiserfs on %s,
reiserfs_bdevname(s));
+ errval = -EINVAL;
goto error;
}
@@ -1610,6 +1613,7 @@ static int reiserfs_fill_super(struct su
You may need to run fsck or increase size of your LVM partition);
SWARN(silent, s,
Or may be you forgot to reboot after fdisk when it told you to);
+ errval = -EINVAL;
goto error;
}
@@ -1649,6 +1653,7 @@ static int reiserfs_fill_super(struct su
if (journal_init(s, jdev_name, old_format, commit_max_age)) {
SWARN(silent, s,
sh-2022: reiserfs_fill_super: unable to initialize journal space);
+ errval = -ENODEV;
goto error;
} else {
jinit_done = 1; /* once this is set, journal_release must be called
@@ -1658,11 +1663,14 @@ static int reiserfs_fill_super(struct su
if (reread_meta_blocks(s)) {
SWARN(silent, s,
jmacd-9: reiserfs_fill_super: unable to reread meta blocks after journal init);
+ errval = -ENODEV;
goto error;
}
- if (replay_only(s))
+ if (replay_only(s)) {
+ errval = -EINVAL;
goto error;
+ }
if (bdev_read_only(s-s_bdev) !(s-s_flags MS_RDONLY)) {
SWARN(silent, s,
@@ -1677,6 +1685,7 @@ static int reiserfs_fill_super(struct su
if (!root_inode) {
SWARN(silent, s,
jmacd-10: reiserfs_fill_super: get root inode failed);
+ errval = -ENODEV;
goto error;
}
@@ -1688,6 +1697,7 @@ static int reiserfs_fill_super(struct su
s-s_root = d_alloc_root(root_inode);
if (!s-s_root) {
iput(root_inode);
+ errval = -ENOMEM;
goto error;
}
// define and initialize hash function
@@ -1695,6 +1705,7 @@ static int
Re: Reiser FS will not boot after crash
Hello On Monday 04 September 2006 23:26, [EMAIL PROTECTED] wrote: Hi, I am observing the following Reiser failure: I am trying to use camorama with a Creative WebCam Live spca5xx driver (recently downloaded and compiled) . Camorama does not start and computer freezes (no response to mouse, or keyboard. Can't change to terminal window. Reset or pull plug leaves Knoppix 5.0.1-DVD unbootable: The actual message from GRUB is inconsistent filesystem?! From a boot loader? after unclean shutdown journal reply is necessary to return reiserfs to consistent state. Maybe GRUB did not do that? The 'fix' is even stranger. I execute fsck.reiserfs from another OS partition on the Knoppix 5.0.1-DVD partition (takes forever). Did fsck complete? What did it report? Somehow 'reading' the Knoppix filesystem 'fixes' whatever was preventing Knoppix 5.0.1-DVD from booting. fsck replayed the journal. Does camorama work now? If it still causes computer freeze - can you please install serial or network console and try to catch what does kernel output when it freezes. I am curious what your comments and/or suggestions might be? regards to all Linuxers, john
Re: Reiser FS will not boot after crash
Hello On Tuesday 05 September 2006 00:30, [EMAIL PROTECTED] wrote: On Mon, 04 Sep 2006 23:33:27 +0400, Vladimir V. Saveliev said: after unclean shutdown journal reply is necessary to return reiserfs to consistent state. Maybe GRUB did not do that? A case can be made that GRUB should be keeping its grubby little paws off the filesystem journal. It's a *bootloader*. It's only purpose in life is to load other code that can make intelligent decisions about things like how (or even whether) to replay a filesystem journal. Yes, I did not say that grub has to replay a journal, I just tried to guess why grub failed to boot and why things went ok after fsck.
Re: FEATURE Req: integrate badblocks check into fsck.reiser*
Hello On Friday 01 September 2006 22:23, Peter wrote: Perhaps this has been mentioned before. If so, sorry. IMHO, it would be useful to integrate a call to badblocks in the fsck/mkfs.reiser* programs so that more thorough disk checking can be done at format time. Sort of like the option e2fsck -c. If this is added, the output could be fed immediately to the reiser format program and badblocks spared prior to filesystem use. JM$0.02 both mkfs.reiserfs and fsck.reiserfs have -B option to accept list of bad blocks. We thought that should be enough.
Re: reiser4-2.6.18-rc2-mm1: possible circular locking dependency detected in txn_end
Hello
On Saturday 12 August 2006 17:26, Laurent Riffard wrote:
Le 03.08.2006 17:07, Laurent Riffard a écrit :
Le 03.08.2006 08:09, Alexander Zarochentsev a écrit :
On Tuesday 01 August 2006 01:29, Laurent Riffard wrote:
Le 31.07.2006 21:55, Vladimir V. Saveliev a écrit :
Hello
What kind of load did you run on reiser4 at that time?
I just formatted a new 2GB Reiser4 FS, then I moved a whole ccache
cache tree to this new FS (cache size was about 20~30 Mbytes).
Something like:
# mkfs.reiser4 /dev/vglinux1/ccache
# mount -tauto -onoatime /dev/vglinux1/ccache /mnt/disk
# mv ~laurent/.ccache/* /mnt/disk/
I was not able to reproduce it. Can you please try the following patch?
lock validator friendly locking of new atom in
atom_begin_and_assign_to_txnh and locking of two atoms.
Signed-off-by: Alexander Zarochentsev [EMAIL PROTECTED]
---
fs/reiser4/txnmgr.c | 14 --
fs/reiser4/txnmgr.h | 15 +++
2 files changed, 23 insertions(+), 6 deletions(-)
[patch snipped]
I tried this patch: it's slow as hell (CPU is ~100% system) and it
panics when syncing...
reiser4 panicked cowardly: reiser4[shutdown(1904)]: spin_lock_atom
(fs/reiser4/txmgr.h:509)[]:
Hello,
I tried again with linux 2.6.18-rc3-mm2+hotfixes.
# booted to runlevel 1
~$ mount
...
/dev/mapper/vglinux1-lvhome on /home type reiserfs (rw)
/dev/mapper/vglinux1-lvccache on /home/laurent/.ccache type reiser4
(rw,nosuid,nodev,noatime) ...
~$ df ~/.ccache
FilesystemSize Used Avail Use% Mounted on
/dev/mapper/vglinux1-lvccache
2.0G 53M 1.9G 3% /home/laurent/.ccache
~$ time mv ~/.ccache/* ~/tmp/ccache
0.10user 6.01system 0:07.92elapsed 77%CPU (0avgtext+0avgdata
0maxresident)k 0inputs+0outputs (1major+296minor)pagefaults 0swaps
dmesg output:
===
[ INFO: possible circular locking dependency detected ]
---
mv/1255 is trying to acquire lock:
(txnh-hlock){--..}, at: [e101f0cf] txn_end+0x191/0x368 [reiser4]
but task is already holding lock:
(atom-alock){--..}, at: [e101b674] txnh_get_atom+0xf6/0x39e
[reiser4]
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
- #1 (atom-alock){--..}:
[c012ce82] lock_acquire+0x60/0x80
[c0291c08] _spin_lock+0x19/0x28
[e101cc0b] try_capture+0x7cf/0x1cd7 [reiser4]
[e10096e5] longterm_lock_znode+0x427/0x84f [reiser4]
[e1038fe7] seal_validate+0x221/0x5ee [reiser4]
[e10652a1] find_entry+0x126/0x307 [reiser4]
[e1065974] rem_entry_common+0xe9/0x4ba [reiser4]
[e104c9bc] unlink_common+0x258/0x364 [reiser4]
[c015f7bc] vfs_unlink+0x47/0x87
[c01611b4] do_unlinkat+0x8c/0x122
[c016125a] sys_unlink+0x10/0x12
[c0102c39] sysenter_past_esp+0x56/0x8d
- #0 (txnh-hlock){--..}:
[c012ce82] lock_acquire+0x60/0x80
[c0291c08] _spin_lock+0x19/0x28
[e101f0cf] txn_end+0x191/0x368 [reiser4]
[e10109b5] reiser4_exit_context+0x1c2/0x571 [reiser4]
[e104cabd] unlink_common+0x359/0x364 [reiser4]
[c015f7bc] vfs_unlink+0x47/0x87
[c01611b4] do_unlinkat+0x8c/0x122
[c016125a] sys_unlink+0x10/0x12
[c0102c39] sysenter_past_esp+0x56/0x8d
other info that might help us debug this:
3 locks held by mv/1255:
#0: (inode-i_mutex/1){--..}, at: [c0161181]
do_unlinkat+0x59/0x122 #1: (inode-i_mutex){--..}, at: [c0290a94]
mutex_lock+0x21/0x24 #2: (atom-alock){--..}, at: [e101b674]
txnh_get_atom+0xf6/0x39e [reiser4]
stack backtrace:
[c0103a97] show_trace+0xd/0x10
[c0103ff6] dump_stack+0x19/0x1b
[c012c20d] print_circular_bug_tail+0x59/0x64
[c012ca2c] __lock_acquire+0x814/0x9a5
[c012ce82] lock_acquire+0x60/0x80
[c0291c08] _spin_lock+0x19/0x28
[e101f0cf] txn_end+0x191/0x368 [reiser4]
[e10109b5] reiser4_exit_context+0x1c2/0x571 [reiser4]
[e104cabd] unlink_common+0x359/0x364 [reiser4]
[c015f7bc] vfs_unlink+0x47/0x87
[c01611b4] do_unlinkat+0x8c/0x122
[c016125a] sys_unlink+0x10/0x12
[c0102c39] sysenter_past_esp+0x56/0x8d
~$ time sync
0.00user 0.02system 0:00.49elapsed 4%CPU (0avgtext+0avgdata
0maxresident)k 0inputs+0outputs (1major+202minor)pagefaults 0swaps
Move the files backward...
~$ time mv ~/tmp/ccache/* ~/.ccache/
0.11user 3.98system 0:04.09elapsed 100%CPU (0avgtext+0avgdata
0maxresident)k 0inputs+0outputs (0major+286minor)pagefaults 0swaps
~$ time sync
0.00user 0.00system 0:01.86elapsed 0%CPU (0avgtext+0avgdata
0maxresident)k 0inputs+0outputs (0major+204minor)pagefaults 0swaps
So this problem still
Re: some testing questions
Hello On Friday 11 August 2006 21:44, Gasper Azman wrote: Hello everyone, especially the namesys team. I have been reading this list for quite some time, and saw that issues of fragmentation have again arisen. So, a decision was made to put the portage tree on a separate reiser4 partition, and to benchmark it over time. Because I know I'm not the smartest guy in the universe, I'm asking everyone here which data they would require (or want to see), how to obtain it (program names would suffice, but other advice will not go amiss) and how frequently the analysis is to be run. reiser4progs incluses a program measurefs.reiser4. It should be able to measure tree fragmentation. I am not sure how does portage tree evolve, but maybe it could be interesting too see how does reiser4 tree fragmentation change when filesystem is loaded regularly. Since this would be a new partition with nothing but the portage tree, it is an ideal and clean environment for testing a specific feature of reiser4 (as has been frequently mentioned). I hope to make a small contribution to the development of IMHO the most promising filesystem since ext3. :) Keep it up, Gasper
Re: [nikita-3002]: assertion failed: carry_level_invariant(doing, CARRY_DOING)
Hello On Thursday 10 August 2006 21:55, Andrew James Wade wrote: Hello, I've had another panic on a fscked filesystem: reiser4 panicked cowardly: reiser4[updatedb(3302)]: reiser4_writepage (fs/reiser4/page_cache.c:521)[]: assertion failed: can_hit_entd(ctx, s) Kernel panic - not syncing: reiser4[updatedb(3302)]: reiser4_writepage (fs/reiser4/page_cache.c:521)[]: assertion failed: can_hit_entd(ctx, s) What kernel do you use? Recently we had few fixes of such problem. It's getting pretty obvious that there must be something unusual/unique in my setup that's giving me grief. My guess would be that data is getting corrupted going between the drive and memory. I do have my pci bus underclocked to 30 MHz so maybe that's a factor. I have had problems with memory corruption in the past (hence the underclocking), but I haven't had any of the symptoms of memory corruption re-appearing. (Note that /dev/hdb is my /home filesystem only, so it's plausible that problems there would mostly tickle reiser4 code). If that's what is going on, I would expect file contents to also corrupt. I'm going to whip up some scripts to exercise the reading and writing large amounts of data to the disk and and see if I can find corruption of the data. (I hope to be able to use O_DIRECT to avoid thrashing). I suppose another possibility is that there is something strange in my filesystem that survives fsck, but causes problems. Given the variety of symptoms (and the lack of other reports) I would tend to discount that though. For the record this is what fsck keeps telling me: FSCK: Node (33160105), item (0), [29:1(SD):0:2a:0]: the slot (9) contains the invalid opset member (compress mode), id (2). FSCK: Node (33160105), item (0), [29:1(SD):0:2a:0]: removing broken slots. FSCK: Node (33160105), item (0), [29:1(SD):0:2a:0]: item has the wrong length (94). Should be (90). Fixed. I'm going to run fsck twice in a row to verify that fsck fixes the problems, but I'm working under the assumption that what fsck is finding is unrelated. I think the ball is in my court: fortunately I now have time to devote to investigation. I'll let you know what I find. Comments? Andrew Wade
Re: reiser4: maybe just fix bugs?
Hello On Mon, 2006-07-31 at 20:18 -0600, Hans Reiser wrote: Andrew Morton wrote: The writeout code is ugly, although that's largely due to a mismatch between what reiser4 wants to do and what the VFS/MM expects it to do. Yes. reiser4 writeouts atoms. Most of pages get into atoms via sys_write. But pages dirtied via shared mapping do not. They get into atoms in reiser4's writepages address space operation. That is why reiser4_sync_inodes has two steps: on first one it calls generic_sync_sb_inodes to call writepages for dirty inodes to capture pages dirtied via shared mapping into atoms. Second step flushes atoms. I agree --- both with it being ugly, and that being part of why. If it works, we can live with it, although perhaps the VFS could be made smarter. I would be curious regarding any ideas on that. Next time I read through that code, I will keep in mind that you are open to making VFS changes if it improves things, and I will try to get clever somehow and send it by you. Our squalloc code though is I must say the most complicated and ugliest piece of code I ever worked on for which every cumulative ugliness had a substantive performance advantage requiring us to keep it. If you spare yourself from reading that, it is understandable to do so. I'd say that resier4's major problem is the lack of xattrs, acls and direct-io. That's likely to significantly limit its vendor uptake. xattrs is really a problem.
Re: reiser4: maybe just fix bugs?
Hello On Tue, 2006-08-01 at 07:33 -0700, Andrew Morton wrote: On Tue, 01 Aug 2006 15:24:37 +0400 Vladimir V. Saveliev [EMAIL PROTECTED] wrote: The writeout code is ugly, although that's largely due to a mismatch between what reiser4 wants to do and what the VFS/MM expects it to do. Yes. reiser4 writeouts atoms. Most of pages get into atoms via sys_write. But pages dirtied via shared mapping do not. They get into atoms in reiser4's writepages address space operation. It think you mean -writepage - reiser4 desn't implement -writepages(). no. there is one. It is reiser4/plugin/file/file.c:writepages_unix_file(). reiser4_writepage just kicks kernel thread (entd) which works similar to reiser4_sync_inodes() (described earlier) and waits until several pages (including the one reiser4_writepage is called with) are written. I assume you considered hooking into -set_page_dirty() to do the add-to-atom thing earlier on? Currently, add-to-atom is not simple. It may require memory allocations and disk i/o-s. I guess these are not supposed to be called in -set_page_dirty(). That is why in reiser4_set_page_dirty we just mark the page in mapping's tree and dealy adding to atoms until flush time. We'll merge mm-tracking-shared-dirty-pages.patch into 2.6.19-rc1, which would make that approach considerably more successful, I expect. -set_page_dirty() is a bit awkward because it can be called under spinlock. Maybe comething could also be gained from the new vm_operations_struct.page_mkwrite(), although that's less obvious... That is why reiser4_sync_inodes has two steps: on first one it calls generic_sync_sb_inodes to call writepages for dirty inodes to capture pages dirtied via shared mapping into atoms. Second step flushes atoms. I agree --- both with it being ugly, and that being part of why. If it works, we can live with it, although perhaps the VFS could be made smarter. I would be curious regarding any ideas on that. Next time I read through that code, I will keep in mind that you are open to making VFS changes if it improves things, and I will try to get clever somehow and send it by you. Our squalloc code though is I must say the most complicated and ugliest piece of code I ever worked on for which every cumulative ugliness had a substantive performance advantage requiring us to keep it. If you spare yourself from reading that, it is understandable to do so. I'd say that resier4's major problem is the lack of xattrs, acls and direct-io. That's likely to significantly limit its vendor uptake. xattrs is really a problem. That's not good. The ability to properly support SELinux is likely to be important. Do you think that if reiser4 supported xattrs - it would increase its chances on inclusion? PS: what exactly did you refer to when you said that writeout code is ugly?
Re: metadata plugins (was Re: the 'official' point of view expressed by kernelnewbies.org regarding reiser4 inclusion)
Hello On Tue, 2006-08-01 at 17:32 +0200, Łukasz Mierzwa wrote: Dnia Fri, 28 Jul 2006 18:33:56 +0200, Linus Torvalds [EMAIL PROTECTED] napisał: In other words, if a filesystem wants to do something fancy, it needs to do so WITH THE VFS LAYER, not as some plugin architecture of its own. We already have exactly the plugin interface we need, and it literally _is_ the VFS interfaces - you can plug in your own filesystems with register_filesystem(), which in turn indirectly allows you to plug in your per-file and per-directory operations for things like lookup etc. What fancy (beside cryptocompress) does reiser4 do now? it is supposed to provide an ability to easy modify filesystem behaviour in various aspects without breaking compatibility. Can someone point me to a list of things that are required by kernel mainteiners to merge reiser4 into vanilla? list of features reiser4 does not have now: O_DIRECT support - we are working on it now various block size support quota support xattrs and acls list of warnings about reiser4 code: I think that last big list of useful comments (from Christoph Hellwig [EMAIL PROTECTED]) is addressed. Well, except for one minor (I believe) place in file release. Currently, Andrew is trying to find some time to review reiser4 code. I feel like I'm getting lost with current reiser4 status and things that are need to be done. Łukasz Mierzwa
Re: 2.6.18-rc3 - ReiserFS - warning: vs-8115: get_num_ver: not directory or indirect item
Hello On Sun, 2006-07-30 at 22:37 +0200, Philippe Gramoullé wrote: Hello Jesper, On Sun, 30 Jul 2006 19:39:07 +0200 Jesper Juhl [EMAIL PROTECTED] wrote: | they don't seem to have caused any trouble/corruption here, so if you | haven't experienced any problems either I think I'll relax and just | wait for an explanation from some reiserfs folks. | | Thank you for replying - nice to know that I'm not the only one seeing | this and that it's not something that has caused massive troubles for | someone else. I reported such a message back in May 2004 ( kernel 2.6.6-rc3 ), to which Vladimir replied : On Thu, 06 May 2004 14:43:22 +0400 Vladimir Saveliev [EMAIL PROTECTED] wrote: | I guess that warning became obsolete when Oleg [EMAIL PROTECTED] | added possibility to insert long indirect items. Then Hans asked for that warning to be removed, and i guess it must have slipped through the TODO list :) Instead of removing that warning we changed it to not complain about inserted long indirect items. Maybe the warning can be removed completely. The warning was not supposed to ever come up. As long as it does - there is a balancing case which we did not imagine. If anybody can easly reproduce this problem - please let me know. Thanks, Philippe
Re: reiser4-2.6.18-rc2-mm1: possible circular locking dependency detected in txn_end
Hello
What kind of load did you run on reiser4 at that time?
On Sun, 2006-07-30 at 20:57 +0200, Laurent Riffard wrote:
===
[ INFO: possible circular locking dependency detected ]
---
mv/29012 is trying to acquire lock:
(txnh-hlock){--..}, at: [e0c8e09b] txn_end+0x191/0x368 [reiser4]
but task is already holding lock:
(atom-alock){--..}, at: [e0c8a640] txnh_get_atom+0xf6/0x39e
[reiser4]
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
- #1 (atom-alock){--..}:
[c012ce2f] lock_acquire+0x60/0x80
[c0292968] _spin_lock+0x19/0x28
[e0c8bbd7] try_capture+0x7cf/0x1cd7 [reiser4]
[e0c786e1] longterm_lock_znode+0x427/0x84f [reiser4]
[e0ca55dc] coord_by_handle+0x2be/0x7f7 [reiser4]
[e0ca5f89] coord_by_key+0x1e3/0x22d [reiser4]
[e0c7dbd2] insert_by_key+0x8f/0xe0 [reiser4]
[e0cbf7f1] write_sd_by_inode_common+0x361/0x61a [reiser4]
[e0cbfce4] create_object_common+0xf1/0xf6 [reiser4]
[e0cbaebf] create_vfs_object+0x51d/0x732 [reiser4]
[e0cbb1fd] mkdir_common+0x43/0x4b [reiser4]
[c015ed33] vfs_mkdir+0x5a/0x9d
[c0160f5e] sys_mkdirat+0x88/0xc0
[c0160fa6] sys_mkdir+0x10/0x12
[c0102c2d] sysenter_past_esp+0x56/0x8d
- #0 (txnh-hlock){--..}:
[c012ce2f] lock_acquire+0x60/0x80
[c0292968] _spin_lock+0x19/0x28
[e0c8e09b] txn_end+0x191/0x368 [reiser4]
[e0c7f97d] reiser4_exit_context+0x1c2/0x571 [reiser4]
[e0cbb091] create_vfs_object+0x6ef/0x732 [reiser4]
[e0cbb1fd] mkdir_common+0x43/0x4b [reiser4]
[c015ed33] vfs_mkdir+0x5a/0x9d
[c0160f5e] sys_mkdirat+0x88/0xc0
[c0160fa6] sys_mkdir+0x10/0x12
[c0102c2d] sysenter_past_esp+0x56/0x8d
other info that might help us debug this:
2 locks held by mv/29012:
#0: (inode-i_mutex/1){--..}, at: [c015f50b]
lookup_create+0x1d/0x73
#1: (atom-alock){--..}, at: [e0c8a640]
txnh_get_atom+0xf6/0x39e [reiser4]
stack backtrace:
[c0104df0] show_trace+0xd/0x10
[c0104e0c] dump_stack+0x19/0x1d
[c012bc62] print_circular_bug_tail+0x59/0x64
[c012cc3e] __lock_acquire+0x814/0x9a5
[c012ce2f] lock_acquire+0x60/0x80
[c0292968] _spin_lock+0x19/0x28
[e0c8e09b] txn_end+0x191/0x368 [reiser4]
[e0c7f97d] reiser4_exit_context+0x1c2/0x571 [reiser4]
[e0cbb091] create_vfs_object+0x6ef/0x732 [reiser4]
[e0cbb1fd] mkdir_common+0x43/0x4b [reiser4]
[c015ed33] vfs_mkdir+0x5a/0x9d
[c0160f5e] sys_mkdirat+0x88/0xc0
[c0160fa6] sys_mkdir+0x10/0x12
[c0102c2d] sysenter_past_esp+0x56/0x8d
(Linux antares.localdomain 2.6.18-rc2-mm1 #77 Sun Jul 30 15:09:34
CEST 2006 i686 AMD Athlon(TM) XP 1600+ unknown GNU/Linux)
new reiser4 patch for 2.6.17
Hello We removed first version of reiser4 patch for 2.6.17 as it was found not stable. Please try whether ftp://ftp.namesys.com/pub/reiser4-for-2.6/2.6.17/reiser4-for-2.6.17-3.patch.gz is better.
Re: fsck.reiserfs --rebuild-tree out of disk space aborted
Hello On Sat, 2006-07-22 at 08:37 +1000, Joel Heenan wrote: On 7/22/06, Vladimir V. Saveliev [EMAIL PROTECTED] wrote: hello On Fri, 2006-07-21 at 10:09 +1000, Joel Heenan wrote: Hi, I can home about two weeks ago and found my media box locked up. I was able to discover that it had filled up its /dev/md2 partition (mounted on /home) which surprised me because it is 550 gigs. Perhaps mythtv went nuts and used it all up. It was only a temporary thing I was going to move mythtv to another partition anyway and boy I wish I had now :-P. Anyway I rebooted and the fsck said I had to run rebuild-tree. So I ran that and a few days later it said out of disk space, aborted. I can't mount the partition it says No folder found I believe. I tried it a few times with both the reiserfsprogs from etch: ii reiserfsprogs3.6.19-2 User-level tools for ReiserFS filesystems and the latest ones downloaded from the website (3.6.19). I am currently trying it with the -S option. there is no need to use -S in your case. I'm running a custom 2.6.12 kernel which is basically the same as the default debian one except it includes some drivers for my dvico fusion tv tuner. I read that the best way to fix this problem is to dd to a bigger partition but there is really no easy way for me to do that - it will probably involve me purchasing 2x300gig partitions, raiding them, then performing the restore. Please let me know if there is a way I can fix this without going to a bigger partition. You can configure linear raid of the /dev/md2 and some additional device, which does not have to be very big. 100 mb should be enough and should not be hard to allocate for spare. Than you can have something like: raiddev /dev/md3 raid-level linear nr-raid-disks 2 chunk-size 32 persistent-superblock 0 device /dev/md2 raid-disk 0 device /dev/spare raid-disk 1 IMPORTANT NOTE: persistent-superblock has to be set to 0. Than you should run reiserfsck --rebuild-sb /dev/md3 and answer n to Did you use resizer(y/n)[n]: and answer y to Is this ok ? (y/n)[n]: Than run reiserfsck --rebuild-tree. There should be no problem with lack of disk space. Here is output of the fsck: fsck.reiserfs --rebuild-tree /dev/md2 reiserfsck 3.6.19 (2003 www.namesys.com) * ** Do not run the program with --rebuild-tree unless ** ** something is broken and MAKE A BACKUP before using it. ** ** If you have bad sectors on a drive it is usually a bad ** ** idea to continue using it. Then you probably should get ** ** a working hard drive, copy the file system from the bad ** ** drive to the good one -- dd_rescue is a good tool for ** ** that -- and only then run this program. ** ** If you are using the latest reiserfsprogs and it fails ** ** please email bug reports to reiserfs-list@namesys.com, ** ** providing as much information as possible -- your ** ** hardware, kernel, patches, settings, all reiserfsck ** ** messages (including version), the reiserfsck logfile, ** ** check the syslog file for any related information. ** ** If you would like advice on using this program, support ** ** is available for $25 at www.namesys.com/support.html. ** * Will rebuild the filesystem (/dev/md2) tree Will put log info to 'stdout' Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes Replaying journal.. Reiserfs journal '/dev/md2' in blocks [18..8211]: 0 transactions replayed ### reiserfsck --rebuild-tree started at Mon Jul 17 21:41:44 2006 ### Pass 0: ### Pass 0 ### Loading on-disk bitmap .. ok, 116676032 blocks marked used Skipping 11771 blocks (super block, journal, bitmaps) 116664261 blocks will be read 0%20%block 85875092: The number of items (256) is incorrect, should be (1) - corrected block 85875092: The free space (1) is incorrect, should be (208) - corrected pass0: vpf-10110: block 85875092, item (0): Unknown item type found [33488896 65537 0x100 ??? (15)] - deleted left 0, 15065 /seccsec 108413 directory entries were hashed with r5 hash. r5 hash is selected Flushing..finished Read blocks (but not data blocks) 116664261 Leaves among those 87768646 - leaves all contents of which could not be saved and deleted 1 Objectids found 108417 Pass 1 (will try to insert 87768645 leaves): ### Pass 1 ### Looking for allocable blocks
Re: serious Reiser4 fsck problem
Hello On Sat, 2006-07-22 at 12:33 +0200, Dirk wrote: Łukasz Mierzwa wrote: Dnia Sat, 22 Jul 2006 12:08:58 +0200, Dirk [EMAIL PROTECTED] napisał: Hello, will using fsck.reiser4 --build-fs result in data loss? I mean to fix the partition - NOT to lose the data on it.. The manual page is also not very specific about if data will be lost or not when using this option... Using --fix resulted in a message that I should use --build-fs to remove corruption... You will probably end up with some amount of files in lostfound dir, those will be the files that fsck can't recognize from what dir are coming and what are named, depending on what corruption You have there can always be some files that You won't get back. As always, backups are a must have on any fs. The hdd was full and a process was still trying to write and create new files... So I guess those files might end up in lost+found... Just want to make sure that --build-fs will not build a _new_ fs, meaning formatting the fs by formatting it?!? it will not format. This is another mode of recovering. That wasn't very clear from what I'd read in the manual... Dirk
Re: fsck.reiserfs --rebuild-tree out of disk space aborted
hello On Fri, 2006-07-21 at 10:09 +1000, Joel Heenan wrote: Hi, I can home about two weeks ago and found my media box locked up. I was able to discover that it had filled up its /dev/md2 partition (mounted on /home) which surprised me because it is 550 gigs. Perhaps mythtv went nuts and used it all up. It was only a temporary thing I was going to move mythtv to another partition anyway and boy I wish I had now :-P. Anyway I rebooted and the fsck said I had to run rebuild-tree. So I ran that and a few days later it said out of disk space, aborted. I can't mount the partition it says No folder found I believe. I tried it a few times with both the reiserfsprogs from etch: ii reiserfsprogs3.6.19-2 User-level tools for ReiserFS filesystems and the latest ones downloaded from the website (3.6.19). I am currently trying it with the -S option. there is no need to use -S in your case. I'm running a custom 2.6.12 kernel which is basically the same as the default debian one except it includes some drivers for my dvico fusion tv tuner. I read that the best way to fix this problem is to dd to a bigger partition but there is really no easy way for me to do that - it will probably involve me purchasing 2x300gig partitions, raiding them, then performing the restore. Please let me know if there is a way I can fix this without going to a bigger partition. Here is output of the fsck: fsck.reiserfs --rebuild-tree /dev/md2 reiserfsck 3.6.19 (2003 www.namesys.com) * ** Do not run the program with --rebuild-tree unless ** ** something is broken and MAKE A BACKUP before using it. ** ** If you have bad sectors on a drive it is usually a bad ** ** idea to continue using it. Then you probably should get ** ** a working hard drive, copy the file system from the bad ** ** drive to the good one -- dd_rescue is a good tool for ** ** that -- and only then run this program. ** ** If you are using the latest reiserfsprogs and it fails ** ** please email bug reports to reiserfs-list@namesys.com, ** ** providing as much information as possible -- your ** ** hardware, kernel, patches, settings, all reiserfsck ** ** messages (including version), the reiserfsck logfile, ** ** check the syslog file for any related information. ** ** If you would like advice on using this program, support ** ** is available for $25 at www.namesys.com/support.html. ** * Will rebuild the filesystem (/dev/md2) tree Will put log info to 'stdout' Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes Replaying journal.. Reiserfs journal '/dev/md2' in blocks [18..8211]: 0 transactions replayed ### reiserfsck --rebuild-tree started at Mon Jul 17 21:41:44 2006 ### Pass 0: ### Pass 0 ### Loading on-disk bitmap .. ok, 116676032 blocks marked used Skipping 11771 blocks (super block, journal, bitmaps) 116664261 blocks will be read 0%20%block 85875092: The number of items (256) is incorrect, should be (1) - corrected block 85875092: The free space (1) is incorrect, should be (208) - corrected pass0: vpf-10110: block 85875092, item (0): Unknown item type found [33488896 65537 0x100 ??? (15)] - deleted left 0, 15065 /seccsec 108413 directory entries were hashed with r5 hash. r5 hash is selected Flushing..finished Read blocks (but not data blocks) 116664261 Leaves among those 87768646 - leaves all contents of which could not be saved and deleted 1 Objectids found 108417 Pass 1 (will try to insert 87768645 leaves): ### Pass 1 ### Looking for allocable blocks .. finished 0%20%40%..Not enough allocable blocks, checking bitmap...there are 1 allocable blocks, btw I am working on a fix for this problem. But the above output looks suspicious. What kind of files are there, would you describe? Are they long? Did you mount reiserfs with any options? Can you give me ssh access to the filesystem so that I could take a look at it myself? out of disk space Aborted
Re: other system with datacorruption (2.425 + datalogging patches)
Hello On Thu, 2006-07-20 at 14:52 +0200, Francisco Javier Cabello wrote: Hello, I have other system with data corruption. were there unclean shutdowns? how do you decide when to reiserfsck? can you please set hdparm -W 0 for systems which corrupts often and check if that will change anything? I send you the output of 'reiserfsck --check' not good. Is there a chance to try whether data gets corrupted on 2.6.17? Can you also try to reproduce corruption on kernel not patched with datalogging patches? I ask because I guess that you are encountering problems which do not present in newer kernels. please describe the load in more details: how many processes do write to a filesystem at the same time? is that filesystem the only reiserfs one in the system dedicated especially for video recording? What is directory structures? How long does it take to get filesystem corrupted? etc. The more details the better
Re: backporting?
Hello On Tue, 2006-07-18 at 16:03 -0500, David Masover wrote: I also wanted to say that I'm back -- all problems with my mailserver bouncing messages should be fixed now. But I do have a legitimate question: I get my Reiser4 as the reiser4-for-2.6 patches. Do new versions ever get backported to older kernel versions? I am sorry to say, but, no. The latest is against 2.6.17. This is not a feature request -- if there's no backport, I'll do without. I'm currently stuck on 2.6.13.4 because of a network driver, but it's probably easier to fix a network driver than to backport a filesystem.
Re: reiser4 OOPSes and panics when out of memory
Hello
On Wed, 2006-07-19 at 07:28 -0600, Jake Maciejewski wrote:
Thanks. Now with debug enabled I've gotten:
http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060719/panic1.txt.gz
the attached patch fixes a problem nikita-2967 reports about. Would you
please check whther it helps.
http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060719/fsck1_--check.txt.gz
http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060719/fsck1_--fix.txt.gz
http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060719/fsck1_--check_after_--fix.txt.gz
and
http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060719/messages2.txt.gz
followed by
http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060719/messages2b.txt.gz
and without debug:
http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060719/messages3.txt.gz
http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060719/fsck3_--check.txt.gz
http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060719/fsck3_--fix.txt.gz
http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060719/fsck3_--check_after_--fix.txt.gz
On Tue, 2006-07-18 at 18:18 +0400, Vladimir V. Saveliev wrote:
Hello
On Tue, 2006-07-18 at 00:52 -0600, Jake Maciejewski wrote:
Thanks for the patch, but I can still reproduce the problem. I've been
running the attached program to try to speed up the testing process a
bit. Interrupting and restarting the compilation loop also seems to
help.
ok
If I had hours to wait, it would probably crash eventually without
additional encouragement, but I'm doing everything as an unprivileged
user, so I don't think my tests are unreasonable.
Anyway, I'm still getting a panic with debug enabled:
reiser4 panicked cowardly: reiser4[find(16411)]: reiser4_dirty_inode
(fs/reiser4/super_ops.c:173)[]:
Kernel panic - not syncing: reiser4[find(16411)]: reiser4_dirty_inode
(fs/reiser4/super_ops.c:173)[]:
The attached patch should fix the above.
Without debug enabled I've seen:
http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060718/messages1.txt.gz
http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060718/fsck1_--check.txt.gz
http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060718/fsck1_--fix.txt.gz
http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060718/fsck1_--check_after_--fix.txt.gz
but usually I get:
http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060718/messages3.txt.gz
with no corruption (although I've been rebooting before complete
failure).
On Mon, 2006-07-17 at 21:38 +0400, Vladimir V. Saveliev wrote:
Hello
On Mon, 2006-07-17 at 18:10 +0400, Vladimir V. Saveliev wrote:
Hello
On Sun, 2006-07-16 at 12:44 -0500, [EMAIL PROTECTED] wrote:
Has my previous post
(http://marc.theaimsgroup.com/?l=reiserfsm=115259665831650w=2)
been
overlooked, or have I not provided enough information? Do I need to
reproduce these issues on 2.6.18-rc1-mm2? Should I be trying any
patches?
please try the attached patch.
your test crashes reiser4 on my test box. I hope to get a patch ready
later today. Not sure that I got the same problem as you, though. We
will see.
The bottom line is with 2.6.17-mm6, I've always been able to OOPs
or panic
reiser4 on my amd64 machine (haven't tried x86 yet) by using all
available
physical memory.
diff -puN fs/reiser4/plugin/file/file.c~reiser4-add-missing-unlock fs/reiser4/plugin/file/file.c
--- linux-2.6.17-mm6/fs/reiser4/plugin/file/file.c~reiser4-add-missing-unlock 2006-07-19 18:12:14.0 +0400
+++ linux-2.6.17-mm6-vs/fs/reiser4/plugin/file/file.c 2006-07-19 18:13:50.0 +0400
@@ -1636,14 +1636,18 @@ static size_t read_file(hint_t * hint, s
/* error happened */
break;
- if (coord-between != AT_UNIT)
+ if (coord-between != AT_UNIT) {
/* there were no items corresponding to given offset */
+ done_lh(hint-ext_coord.lh);
break;
+ }
loaded = coord-node;
result = zload(loaded);
- if (unlikely(result))
+ if (unlikely(result)) {
+ done_lh(hint-ext_coord.lh);
break;
+ }
if (hint-ext_coord.valid == 0)
validate_extended_coord(hint-ext_coord,
_
Re: vs-6030
Hello On Mon, 2006-07-17 at 18:30 +0200, Adrian Ulrich wrote: Would the system crash if you dd to another directory of the filesystem? Writing/dd'ing to other directories (= *not* subdirectories of the homedir) worked fine. Would you please recompile with reiserfs debug on and crash again and send us all kernel output related to the crash? Hmm.. The owner of the System has already removed the broken directory :-/ .. All i've got is a metadump of the FS .. Sorry.. ok, where can I download it from? -- Adrian
Re: reiser4: possible circular locking dependency
Hello
On Sun, 2006-07-16 at 12:24 +0200, Laurent Riffard wrote:
Hello,
I just got this warning:
===
[ INFO: possible circular locking dependency detected ]
---
nautilus/3229 is trying to acquire lock:
(txnh-hlock){--..}, at: [e0c8e09b] txn_end+0x191/0x368 [reiser4]
but task is already holding lock:
(atom-alock){--..}, at: [e0c8a640] txnh_get_atom+0xf6/0x39e [reiser4]
which lock already depends on the new lock.
lock validator is too severe. I guess that it thinks that
txnh_get_atom() breaks lock ordering. This warning can be ignored.
the existing dependency chain (in reverse order) is:
- #1 (atom-alock){--..}:
[c012d1a7] lock_acquire+0x60/0x80
[c02924f8] _spin_lock+0x19/0x28
[e0c8bbd7] try_capture+0x7cf/0x1cd7 [reiser4]
[e0c786e1] longterm_lock_znode+0x427/0x84f [reiser4]
[e0ca7fcb] seal_validate+0x221/0x5ee [reiser4]
[e0cbefb1] update_sd+0x1c5/0x6a0 [reiser4]
[e0cbfa37] write_sd_by_inode_common+0x5ab/0x61a [reiser4]
[e0cb428b] reiser4_update_sd+0x83/0x8c [reiser4]
[e0caba2f] reiser4_dirty_inode+0xea/0x143 [reiser4]
[c017062d] __mark_inode_dirty+0x2a/0x156
[c0169650] touch_atime+0x89/0x91
[e0cbe010] readdir_common+0x7da/0x848 [reiser4]
[c0162c4f] vfs_readdir+0x4e/0x7a
[c0162cd9] sys_getdents64+0x5e/0xa0
[c0102c2d] sysenter_past_esp+0x56/0x8d
- #0 (txnh-hlock){--..}:
[c012d1a7] lock_acquire+0x60/0x80
[c02924f8] _spin_lock+0x19/0x28
[e0c8e09b] txn_end+0x191/0x368 [reiser4]
[e0c7f97d] reiser4_exit_context+0x1c2/0x571 [reiser4]
[e0cbe02e] readdir_common+0x7f8/0x848 [reiser4]
[c0162c4f] vfs_readdir+0x4e/0x7a
[c0162cd9] sys_getdents64+0x5e/0xa0
[c0102c2d] sysenter_past_esp+0x56/0x8d
other info that might help us debug this:
2 locks held by nautilus/3229:
#0: (inode-i_mutex){--..}, at: [c02913aa] mutex_lock+0x21/0x24
#1: (atom-alock){--..}, at: [e0c8a640] txnh_get_atom+0xf6/0x39e
[reiser4]
stack backtrace:
[c0104db5] show_trace+0xd/0x10
[c0104dd1] dump_stack+0x19/0x1c
[c012bfda] print_circular_bug_tail+0x59/0x64
[c012cfb6] __lock_acquire+0x814/0x9a5
[c012d1a7] lock_acquire+0x60/0x80
[c02924f8] _spin_lock+0x19/0x28
[e0c8e09b] txn_end+0x191/0x368 [reiser4]
[e0c7f97d] reiser4_exit_context+0x1c2/0x571 [reiser4]
[e0cbe02e] readdir_common+0x7f8/0x848 [reiser4]
[c0162c4f] vfs_readdir+0x4e/0x7a
[c0162cd9] sys_getdents64+0x5e/0xa0
[c0102c2d] sysenter_past_esp+0x56/0x8d
I'm running 2.6.18-rc1-mm2 with a few patches:
- drivers-base-check-errors-fix.patch (hot-fixes)
- annotate-pktcdvd-natural-device-hierarchy.patch (from Arjan van de Ven)
- blkdev_get_partition.patch (from Peter Osterlund)
.config is attached
--
laurent
plain text document attachment (config-2.6.18-rc1-mm2)
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.18-rc1-mm2
# Sun Jul 16 12:05:34 2006
#
CONFIG_X86_32=y
CONFIG_GENERIC_TIME=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_SEMAPHORE_SLEEPERS=y
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_DMI=y
CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config
#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
#
# General setup
#
CONFIG_LOCALVERSION=
CONFIG_LOCALVERSION_AUTO=y
CONFIG_SWAP=y
CONFIG_SWAP_PREFETCH=y
CONFIG_SYSVIPC=y
# CONFIG_IPC_NS is not set
CONFIG_POSIX_MQUEUE=y
# CONFIG_BSD_PROCESS_ACCT is not set
# CONFIG_TASKSTATS is not set
CONFIG_SYSCTL=y
CONFIG_SYSCTL_SYSCALL=y
# CONFIG_UTS_NS is not set
# CONFIG_AUDIT is not set
# CONFIG_IKCONFIG is not set
# CONFIG_RELAY is not set
CONFIG_INITRAMFS_SOURCE=
CONFIG_KLIBC_ERRLIST=y
CONFIG_KLIBC_ZLIB=y
CONFIG_UID16=y
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_EMBEDDED=y
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_RT_MUTEXES=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SHMEM=y
CONFIG_SLAB=y
CONFIG_VM_EVENT_COUNTERS=y
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
# CONFIG_SLOB is not set
#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
# CONFIG_MODVERSIONS is not set
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_KMOD=y
#
# Block layer
#
# CONFIG_LBD is not set
# CONFIG_BLK_DEV_IO_TRACE is not set
# CONFIG_LSF is not set
#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
# CONFIG_DEFAULT_AS is not set
# CONFIG_DEFAULT_DEADLINE is not set
CONFIG_DEFAULT_CFQ=y
# CONFIG_DEFAULT_NOOP is
Re: reiser4 OOPSes and panics when out of memory
Hello On Tue, 2006-07-18 at 00:52 -0600, Jake Maciejewski wrote: Thanks for the patch, but I can still reproduce the problem. I've been running the attached program to try to speed up the testing process a bit. Interrupting and restarting the compilation loop also seems to help. ok If I had hours to wait, it would probably crash eventually without additional encouragement, but I'm doing everything as an unprivileged user, so I don't think my tests are unreasonable. Anyway, I'm still getting a panic with debug enabled: reiser4 panicked cowardly: reiser4[find(16411)]: reiser4_dirty_inode (fs/reiser4/super_ops.c:173)[]: Kernel panic - not syncing: reiser4[find(16411)]: reiser4_dirty_inode (fs/reiser4/super_ops.c:173)[]: The attached patch should fix the above. Without debug enabled I've seen: http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060718/messages1.txt.gz http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060718/fsck1_--check.txt.gz http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060718/fsck1_--fix.txt.gz http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060718/fsck1_--check_after_--fix.txt.gz but usually I get: http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060718/messages3.txt.gz with no corruption (although I've been rebooting before complete failure). On Mon, 2006-07-17 at 21:38 +0400, Vladimir V. Saveliev wrote: Hello On Mon, 2006-07-17 at 18:10 +0400, Vladimir V. Saveliev wrote: Hello On Sun, 2006-07-16 at 12:44 -0500, [EMAIL PROTECTED] wrote: Has my previous post (http://marc.theaimsgroup.com/?l=reiserfsm=115259665831650w=2) been overlooked, or have I not provided enough information? Do I need to reproduce these issues on 2.6.18-rc1-mm2? Should I be trying any patches? please try the attached patch. your test crashes reiser4 on my test box. I hope to get a patch ready later today. Not sure that I got the same problem as you, though. We will see. The bottom line is with 2.6.17-mm6, I've always been able to OOPs or panic reiser4 on my amd64 machine (haven't tried x86 yet) by using all available physical memory. readdir has to txn_restart, therefore, grab space for stat data update has to be forced --- commit f1cea9c0a8db0977077d54562677514d6d736690 tree 95479706299276d7c23efd337216501b0dfd69c2 parent bbf99f71c140d7758a6223a557fa4a4d2b5c384e author Vladimir V. Saveliev [EMAIL PROTECTED] Tue, 18 Jul 2006 18:13:05 +0400 committer Vladimir V. Saveliev [EMAIL PROTECTED] Tue, 18 Jul 2006 18:13:05 +0400 plugin/file_ops_readdir.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/plugin/file_ops_readdir.c b/plugin/file_ops_readdir.c index 04ada21..dfdb68d 100644 --- a/plugin/file_ops_readdir.c +++ b/plugin/file_ops_readdir.c @@ -629,7 +629,7 @@ int readdir_common(struct file *f /* dir detach_fsdata(f); /* try to update directory's atime */ - if (reiser4_grab_space(inode_file_plugin(inode)-estimate.update(inode), + if (reiser4_grab_space_force(inode_file_plugin(inode)-estimate.update(inode), BA_CAN_COMMIT) != 0) warning(, failed to update atime on readdir: %llu, get_inode_oid(inode));
Re: reiser4 OOPSes and panics when out of memory
Hello On Sun, 2006-07-16 at 12:44 -0500, [EMAIL PROTECTED] wrote: Has my previous post (http://marc.theaimsgroup.com/?l=reiserfsm=115259665831650w=2) been overlooked, or have I not provided enough information? Do I need to reproduce these issues on 2.6.18-rc1-mm2? Should I be trying any patches? your test crashes reiser4 on my test box. I hope to get a patch ready later today. Not sure that I got the same problem as you, though. We will see. The bottom line is with 2.6.17-mm6, I've always been able to OOPs or panic reiser4 on my amd64 machine (haven't tried x86 yet) by using all available physical memory.
Re: vs-6030
Hello On Mon, 2006-07-17 at 15:15 +0200, Adrian Ulrich wrote: Hi Vladimir, Can you reproduce this easily? If no, please tell more about what did filesystem do when panic occured. I've seen the same problem (vs-6030) today on one of our hosts: It happened as soon as somebody tried to write data to /home/$affected_user/ (..or a subdirectory) eg: dd if=/dev/urandom of=/home/$affected_user/Temp/test always paniced the kernel (2.6.16.11) and reiserfsck didn't show any errors. Would the system crash if you dd to another directory of the filesystem? Would you please recompile with reiserfs debug on and crash again and send us all kernel output related to the crash? I created a metadump of the filesystem, would you like to have a look at it? As long as reiserfsck does not report any errors - there is no need to look at it yet. Regards, Adrian
Re: reiser4 OOPSes and panics when out of memory
Hello
On Mon, 2006-07-17 at 18:10 +0400, Vladimir V. Saveliev wrote:
Hello
On Sun, 2006-07-16 at 12:44 -0500, [EMAIL PROTECTED] wrote:
Has my previous post
(http://marc.theaimsgroup.com/?l=reiserfsm=115259665831650w=2) been
overlooked, or have I not provided enough information? Do I need to
reproduce these issues on 2.6.18-rc1-mm2? Should I be trying any patches?
please try the attached patch.
your test crashes reiser4 on my test box. I hope to get a patch ready
later today. Not sure that I got the same problem as you, though. We
will see.
The bottom line is with 2.6.17-mm6, I've always been able to OOPs or panic
reiser4 on my amd64 machine (haven't tried x86 yet) by using all available
physical memory.
diff -puN fs/reiser4/plugin/file_ops_readdir.c~reiser4-fix-readdir fs/reiser4/plugin/file_ops_readdir.c
--- linux-2.6.17-mm6/fs/reiser4/plugin/file_ops_readdir.c~reiser4-fix-readdir 2006-07-17 18:43:50.0 +0400
+++ linux-2.6.17-mm6-vs/fs/reiser4/plugin/file_ops_readdir.c 2006-07-17 19:02:38.0 +0400
@@ -349,6 +349,7 @@ feed_entry(struct file *f,
*/
assert(nikita-3436, lock_stack_isclean(get_current_lock_stack()));
+ txn_restart_current();
result = filldir(dirent, name, (int)strlen(name),
/* offset of this entry */
f-f_pos,
diff -puN fs/reiser4/plugin/file/file.c~reiser4-fix-readdir fs/reiser4/plugin/file/file.c
--- linux-2.6.17-mm6/fs/reiser4/plugin/file/file.c~reiser4-fix-readdir 2006-07-17 20:39:11.0 +0400
+++ linux-2.6.17-mm6-vs/fs/reiser4/plugin/file/file.c 2006-07-17 21:35:31.0 +0400
@@ -781,9 +781,12 @@ int find_or_create_extent(struct page *p
lock_page(page);
node = jnode_of_page(page);
- unlock_page(page);
- if (IS_ERR(node))
+ if (IS_ERR(node)) {
+ unlock_page(page);
return PTR_ERR(node);
+ }
+ JF_SET(node, JNODE_WRITE_PREPARED);
+ unlock_page(page);
if (node-blocknr == 0) {
plugged_hole = 0;
@@ -791,6 +794,7 @@ int find_or_create_extent(struct page *p
(loff_t)page-index PAGE_CACHE_SHIFT,
plugged_hole);
if (result) {
+ JF_CLR(node, JNODE_WRITE_PREPARED);
jput(node);
warning(, update_extent failed: %d, result);
return result;
@@ -806,6 +810,7 @@ int find_or_create_extent(struct page *p
}
BUG_ON(node-atom == NULL);
+ JF_CLR(node, JNODE_WRITE_PREPARED);
jput(node);
if (get_current_context()-entd) {
@@ -1729,7 +1734,9 @@ ssize_t read_unix_file(struct file *file
return RETERR(-EFAULT);
}
- read = read_file(hint, file, buf, left, off);
+ read = read_file(hint, file, buf,
+ left PAGE_CACHE_SIZE ? PAGE_CACHE_SIZE : left,
+ off);
drop_nonexclusive_access(uf_info);
_
Re: data corruption with 2.4.25 and datalogging patches
Hello On Mon, 2006-07-17 at 10:53 +0200, Francisco Javier Cabello wrote: Hello Vladimir, such corruptions used to be considered as hardware bugs. Memory failure, for instance. Did you ever run memtest on your systems? Yes, We have run memtest in our system. It's very seldom to find a system with a hardware memory problem running. When we find a memory problem the kernel doesn't boot. I am going to pass memtest in some of the system with reiserfs corruption problem. please let it run few hours at least. Could I give you more information? Perhaps if I run 'reiserfsck --rebuild-tree' and I give you the traces... would it be useful? ok, although you sent reiserfsck --check log. The corruption looked like a content of block was randomly overwritten by random characters. We used to consider such corruptions as caused by hardware faults. Especially because most of your systems are running in similar circumstances flawlessly. Regards, Paco On Friday, 14 de July de 2006 14:59, Vladimir V. Saveliev wrote: Hello On Fri, 2006-07-14 at 14:20 +0200, Francisco Javier Cabello wrote: Hello Vladimir, # reiserfsck -l /tmp/reiserfsck.log -y --check /dev/hdc1 Standard output: == Will read-only check consistency of the filesystem on /dev/hdc1 Will put log info to '/tmp/reiserfsck.log' ### reiserfsck --check started at Fri Jul 14 14:09:33 2006 ### Replaying journal.. Reiserfs journal '/dev/hdc1' in blocks [18..8211]: 0 transactions replayed Checking internal tree..finished Comparing bitmaps..Bad nodes were found, Semantic pass skipped 1 found corruptions can be fixed only when running with --rebuild-tree ### reiserfsck finished at Fri Jul 14 14:13:29 2006 ### == /tmp/reiserfsck.log: == bad_internal: vpf-10320: block 23868569, items 91 and 92: The wrong order of items: [410810496 11321 0x16abca00 ??? (15)], [11312 11321 0x22f1c880 DIR (3)] such corruptions used to be considered as hardware bugs. Memory failure, for instance. Did you ever run memtest on your systems? the problem in the internal node occured (23868569), whole subtree is skipped vpf-10640: The on-disk and the correct bitmaps differs. ==
Re: SuSe 9.3 kernel 2.6.11.4-21.11-smp warning: vs-8115: get_num_ver: not directory or indirect item error
Hello
On Fri, 2006-07-14 at 12:16 -0700, Brad Dameron wrote:
I am seeing a lot of these errors:
ReiserFS: sda7: warning: vs-8115: get_num_ver: not directory or indirect
item
it is just interesting case. I think that this warning can be removed if
everything works normally.
But, would you, please, apply the attached patch and reproduce this
warning and send me kernel output so that I can see the case which was
considered impossible.
I did a google search and all I see is emails back from 2004/2005 about
it being a issue with the 2.6.8 kernel. Are these warnings something I
should run reiserfsck on the partition to correct or something I should
ignore? This is on a production server and I would hate to lose the
data.
Thanks,
Brad Dameron
SeaTab Software
www.seatab.com
diff -puN fs/reiserfs/prints.c~reiserfs-debug fs/reiserfs/prints.c
--- linux-2.6.11/fs/reiserfs/prints.c~reiserfs-debug 2006-07-16 23:44:01.0 +0400
+++ linux-2.6.11-vs/fs/reiserfs/prints.c 2006-07-17 00:01:06.0 +0400
@@ -423,10 +423,6 @@ static int print_internal (struct buffer
return 0;
}
-
-
-
-
static int print_leaf (struct buffer_head * bh, int print_mode, int first, int last)
{
struct block_head * blkh;
@@ -725,3 +721,20 @@ bmap with search %d, without %d, dir2ind
*/
}
+
+void print_virtual_node (struct virtual_node * vn)
+{
+int i;
+struct virtual_item * vi;
+
+printk (VIRTUAL NODE CONTAINS %d items, has size %d,%s,%s, ITEM_POS=%d POS_IN_ITEM=%d MODE=\'%c\'\n,
+vn-vn_nr_item, vn-vn_size,
+(vn-vn_vi[0].vi_type VI_TYPE_LEFT_MERGEABLE )? left mergeable : ,
+(vn-vn_vi[vn-vn_nr_item - 1].vi_type VI_TYPE_RIGHT_MERGEABLE) ? right mergeable : ,
+vn-vn_affected_item_num, vn-vn_pos_in_item, vn-vn_mode);
+
+vi = vn-vn_vi;
+for (i = 0; i vn-vn_nr_item; i ++, vi ++)
+op_print_vi (vi);
+
+}
diff -puN fs/reiserfs/fix_node.c~reiserfs-debug fs/reiserfs/fix_node.c
--- linux-2.6.11/fs/reiserfs/fix_node.c~reiserfs-debug 2006-07-16 23:55:09.0 +0400
+++ linux-2.6.11-vs/fs/reiserfs/fix_node.c 2006-07-17 00:09:17.0 +0400
@@ -346,6 +346,8 @@ static void check_right (struct tree_bal
return;
}
+int pvn = 0;
+void print_virtual_node (struct virtual_node * vn);
/*
* from - number of items, which are shifted to left neighbor entirely
@@ -376,6 +378,9 @@ static int get_num_ver (int mode, struct
int split_item_positions[2]; /* these are positions in virtual item of
items, that are split between S[0] and
S1new and S1new and S2new */
+int vs8115;
+
+vs8115 = 0;
split_item_positions[0] = -1;
split_item_positions[1] = -1;
@@ -512,8 +517,11 @@ static int get_num_ver (int mode, struct
if (vn-vn_vi[split_item_num].vi_index != TYPE_DIRENTRY
vn-vn_vi[split_item_num].vi_index != TYPE_INDIRECT)
- reiserfs_warning (tb-tb_sb, vs-8115: get_num_ver: not
+ vs8115 = 1;
+ /*
+ reiserfs_warning (tb-tb_sb, vs-8115: get_num_ver: not
directory or indirect item);
+ */
}
/* now we know S2bytes, calculate S1bytes */
@@ -531,6 +539,14 @@ static int get_num_ver (int mode, struct
snum012[3] = op_unit_num (vn-vn_vi[split_item_num]) - snum012[3] - bytes_to_r - bytes_to_l - bytes_to_S2new;
}
+if (vs8115 == 1 pvn == 0) {
+ print_virtual_node(vn);
+ printk(sip[0] %d, sip[1] %d, snum=[%d %d %d %d %d]\n,
+ split_item_positions[0], split_item_positions[1],
+ snum012[0], snum012[1], snum012[2], snum012[3], snum012[4]);
+ pvn = 1;
+}
+
return needed_nodes;
}
_
Re: data corruption with 2.4.25 and datalogging patches
Hello On Fri, 2006-07-14 at 10:25 +0200, Francisco Javier Cabello wrote: Hello, I am almost sure that unclean shutdowns happen in those systems. We have tried to reproduce removing power each 5 minutes and the filesystem wasn't suffering corruption. Perhaps it's related, but I don't know. I have talked about 'Datalogging patches' because it's the only thing different from our system. sorry, I am confused. Am I correct that you have set of systems and they all run similar load on the same kernel and only ~10% of them encounter reiserfs corruptions? Do they have identical hardware? I have searched a lot and few people have corruption with reiserfs standalone... so, it may be datalogging patches. what do you need from reiserfsck? I guess the output of 'reiserfsck --check device' yes. There is -l option to redirect output to log file. of perhaps you need the output of reiserfsck --rebuild tree. Regards, Paco On Thursday, 13 de July de 2006 16:34, Vladimir V. Saveliev wrote: Hello On Wed, 2006-07-12 at 08:16 +0200, Francisco Javier Cabello wrote: Hello, My company develops video recorder system. Basically we work with linux boxes running kernel 2.4.25. The system captures analogue video, and after processing and compressing, digital video is stored to hard disk. We are recording continuously (24x7). We have realized that more or less a 10% of our systems are suffering data corruption in the reiserfs partition. Did unclean shutdowns take place on those systems? If you let us see what does reiserfsck report in those cases that could help to understand what is is happening. Sometimes it's possible to fix it running 'reiserfsck --rebuild-tree' but not always. More information: -Kernel 2.4.25 + v4l2 patches -Reiserfsprogs 3.6.19 -Datalogging patches. (http://mirror.mcs.anl.gov/suse-people/mason/patches/data-logging/2.4.25/ ) I have checked datalogging patches from Reiserfs website and they seem equal to suse ones. I don't have any idea of what it's happening. The disk bandwidth is not so high (300-500kb/sec). The disk is always full at 90% (we have a process deleting old video). I have been thinking about removing Dataloggin patches but I would like to have serious reason. It's not easy to check that the problem is solved because we are not able to reproduce the error in our headquarter. Regards, Paco
Re: data corruption with 2.4.25 and datalogging patches
Hello On Fri, 2006-07-14 at 14:20 +0200, Francisco Javier Cabello wrote: Hello Vladimir, # reiserfsck -l /tmp/reiserfsck.log -y --check /dev/hdc1 Standard output: == Will read-only check consistency of the filesystem on /dev/hdc1 Will put log info to '/tmp/reiserfsck.log' ### reiserfsck --check started at Fri Jul 14 14:09:33 2006 ### Replaying journal.. Reiserfs journal '/dev/hdc1' in blocks [18..8211]: 0 transactions replayed Checking internal tree..finished Comparing bitmaps..Bad nodes were found, Semantic pass skipped 1 found corruptions can be fixed only when running with --rebuild-tree ### reiserfsck finished at Fri Jul 14 14:13:29 2006 ### == /tmp/reiserfsck.log: == bad_internal: vpf-10320: block 23868569, items 91 and 92: The wrong order of items: [410810496 11321 0x16abca00 ??? (15)], [11312 11321 0x22f1c880 DIR (3)] such corruptions used to be considered as hardware bugs. Memory failure, for instance. Did you ever run memtest on your systems? the problem in the internal node occured (23868569), whole subtree is skipped vpf-10640: The on-disk and the correct bitmaps differs. ==
Re: data corruption with 2.4.25 and datalogging patches
Hello On Wed, 2006-07-12 at 08:16 +0200, Francisco Javier Cabello wrote: Hello, My company develops video recorder system. Basically we work with linux boxes running kernel 2.4.25. The system captures analogue video, and after processing and compressing, digital video is stored to hard disk. We are recording continuously (24x7). We have realized that more or less a 10% of our systems are suffering data corruption in the reiserfs partition. Did unclean shutdowns take place on those systems? If you let us see what does reiserfsck report in those cases that could help to understand what is is happening. Sometimes it's possible to fix it running 'reiserfsck --rebuild-tree' but not always. More information: -Kernel 2.4.25 + v4l2 patches -Reiserfsprogs 3.6.19 -Datalogging patches. (http://mirror.mcs.anl.gov/suse-people/mason/patches/data-logging/2.4.25/) I have checked datalogging patches from Reiserfs website and they seem equal to suse ones. I don't have any idea of what it's happening. The disk bandwidth is not so high (300-500kb/sec). The disk is always full at 90% (we have a process deleting old video). I have been thinking about removing Dataloggin patches but I would like to have serious reason. It's not easy to check that the problem is solved because we are not able to reproduce the error in our headquarter. Regards, Paco
Re: reiser4 oops
Hello On Fri, 2006-07-07 at 01:18 -0600, Jake Maciejewski wrote: It doesn't look like this issue has been fixed: http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060702/reiser4_kio_http.txt.gz Again fsck showed a clean filesystem. Should I try -mm? Yes, please try to check whether latest mm has this problem. This is somewhat difficult to reproduce because the critical factor seems to be using all available memory, however in doing so the system quickly becomes unresponsive. On Mon, 2006-07-03 at 17:23 -0600, Jake Maciejewski wrote: Thanks for the patch. I don't think I'll be able to test it before Wednesday, though. On Mon, 2006-07-03 at 14:10 +0400, Vladimir V. Saveliev wrote: Hello On Sun, 2006-07-02 at 22:24 -0600, Jake Maciejewski wrote: I'm seeing this on 2.6.16.20 with the -4 patch, amd64 with preempt. The OOM killer was called even though I have 1GB RAM and 4GB swap. My logs are available at: http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060702/oom.txt.gz Both affected filesystems (rsync was using one filesystem, cc1 the other) came up clean with fsck. On Sat, 2006-07-01 at 22:08 +0200, Łukasz Mierzwa wrote: I'm running x86 gentoo system with / on reiser4, I'm using suspend-sources-2.6.16-r8 kernel with 2.6.16-4 patch. Today I run emerge --sync, after that I started to compile new xine-lib while browsing net, when xine-lib was finishing I got this errors: kernel BUG at fs/inode.c:253! would you please check whether this patch helps? ftp://ftp.ru.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm5/broken-out/reiser4-run-truncate_inode_pages-in-reiser4_delete_inode.patch invalid opcode: [#1] PREEMPT Modules linked in: ndiswrapper fglrx acer_acpi nsc_ircc irda crc_ccitt snd_atiixp snd_ac97_codec snd_ac97_bus yenta_socket rsrc_nonstatic pcmcia_core tifm_7xx1 tifm_core CPU:0 EIP:0060:[c017bc56]Tainted: P VLI EFLAGS: 00010206 (2.6.16-suspend2-r8 #2) EIP is at clear_inode+0x16/0xb0 eax: 0003 ebx: d5245d20 ecx: edx: d5245df8 esi: df2099c0 edi: c2a3a000 ebp: c2a3a000 esp: c2a3be94 ds: 007b es: 007b ss: 0068 Process emerge (pid: 9123, threadinfo=c2a3a000 task=c2a0ba70) Stack: 0df2099c0 d5245d20 df2099c0 c01db519 c017a385 0400 d5245e28 d5245d20 c2a3a000 d415c114 d5245d20 c01db4e0 c017bd59 d5245d20 dfe9b000 c017b81c d415c114 c017a431 dfe9b000 df533000 c2a3bf50 c0172d74 Call Trace: [c01db519] reiser4_delete_inode+0x39/0xc0 [c017a385] dput+0x25/0x170 [c01db4e0] reiser4_delete_inode+0x0/0xc0 [c017bd59] generic_delete_inode+0x69/0x100 [c017b81c] iput+0x5c/0x70 [c017a431] dput+0xd1/0x170 [c0172d74] sys_renameat+0x1c4/0x1f0 [c0172dc7] sys_rename+0x27/0x30 [c0102ef3] sysenter_past_esp+0x54/0x75 Code: 80 98 00 00 00 8b 40 38 eb c4 8d 74 26 00 8d bc 27 00 00 00 00 56 53 89 c3 83 ec 04 e8 14 b0 fe ff 8b 83 c4 00 00 00 85 c0 74 08 0f 0b fd 00 ab d4 37 c0 8b 83 20 01 00 00 a8 10 75 08 0f 0b ff 4reiser4[emerge(9123)]: release_unix_file (fs/reiser4/plugin/file/file.c:2294)[vs-44]: WARNING: out of memory? reiser4[emerge(9123)]: release_unix_file (fs/reiser4/plugin/file/file.c:2294)[vs-44]: WARNING: out of memory? reiser4[emerge(9123)]: release_unix_file (fs/reiser4/plugin/file/file.c:2294)[vs-44]: WARNING: out of memory? reiser4[emerge(9123)]: release_unix_file (fs/reiser4/plugin/file/file.c:2294)[vs-44]: WARNING: out of memory? reiser4[emerge(9123)]: release_unix_file (fs/reiser4/plugin/file/file.c:2294)[vs-44]: WARNING: out of memory? reiser4[emerge(9123)]: release_unix_file (fs/reiser4/plugin/file/file.c:2294)[vs-44]: WARNING: out of memory? reiser4[emerge(9123)]: release_unix_file (fs/reiser4/plugin/file/file.c:2294)[vs-44]: WARNING: out of memory? reiser4[emerge(9123)]: release_unix_file (fs/reiser4/plugin/file/file.c:2294)[vs-44]: WARNING: out of memory? reiser4
Re: Reiser4 on top of software raid 0 (dmraid) - another problem
Hello On Tue, 2006-07-04 at 14:56 -0400, Diego Pinheiro wrote: I'm having another problem when running reiser4 on top of software raid 0 (dmraid)... I can work the filesystem fine (mount, copy, create, delete, move, etc...) - even big ammount of data ( 3Gb) as a separate (non / - root folder) filesystem. But if I try to mount this filesystem as the root filesystem I get a segmentation fault in the init script (in the process to update the /etc/mtab file (line 413 Fedora Core 5 init script). The line mount -f / goes fine; but the line mount -f /proc generates the error)... We need to see the error. Would you, please, setup serial or net console and catch the output? The same procedure with a ext3 filesystem goes fine, so apparently it's not the init script, neither the software raid or the kernel (2.6.16.22 with 2.6.16-4 reiser4 patch) Any ideas? Thanks, Diego
Re: Reiser4 Kernel OOPS on fs/reiser4/plugin/file/file.c:2294 (perhaps the same as the one reported in 2006-07-03 22:24:29?)
Hello On Tue, 2006-07-04 at 17:56 -0500, Skotlex wrote: Hello. Am new to this mailing list.. and I only joined because I can't find any other place to look up bug reports and the like. Anyway, I have a kernel oops on Kernel 2.6.16 with the patchset -4. Is this the same as the one from that other mail posted on the mailing archives, which I have no idea how to reference it from here... the meta-data of such email is: List: reiserfs Subject:Re: reiser4 oops From: Jake Maciejewski maciejej () msoe ! edu Date: 2006-07-03 22:24:29 Message-ID: 1151969007.10172.23.camel () gentoo Looking at the trace, it hang on the same file, same line. Should I try the patch provided on that email, then? Point worth noting: The problem no longer is present when running 2.6.14, -1 patch Oops: [#1] Modules linked in: sch_ingress cls_u32 usblp cdc_ether joydev nvidia usbnet evdev ehci_hcd ohci_hcd CPU:0 EIP:0060:[c01310f5]Tainted: P VLI EFLAGS: 00010213 (2.6.16-reiser4-r9 #2) EIP is at truncate_inode_pages_range+0x38/0x275 eax: ebx: 1fff ecx: 1fff edx: esi: edi: 0001 ebp: esp: eb737860 ds: 007b es: 007b ss: 0068 Process ldconfig (pid: 5748, threadinfo=eb736000 task=f66e4050) Stack: 0 eb7378a4 0001 eb7378a4 eb7378a4 c1717f80 c0130df6 eb7378ac 0001 0040 0002 0010 003f eb356c3c c01de9b1 eb356c3c c1717080 0002 0001 c01a0f57 Call Trace: [c0130df6] __pagevec_release+0x18/0x23 [c01de9b1] radix_tree_gang_lookup+0x3c/0x54 [c01a0f57] invalidate_unformatted+0x41/0x65 [c01a100f] truncate_jnodes_range+0x94/0xcd [c01be47b] kill_hook_extent+0x3f0/0x557 [c01be6e5] kill_units_extent+0x103/0x230 [c01b5d35] kill_tail+0x0/0x32 [c01b5ce2] kill_units+0x0/0x53 [c01b55ed] parse_cut+0x3e/0x694 [c01b5d67] kill_head+0x0/0x24 [c01b5d2b] kill_units+0x49/0x53 [c01b5ce2] kill_units+0x0/0x53 [c01b5d84] kill_head+0x1d/0x24 [c01b6022] prepare_for_compact+0x1ea/0x411 [c01905b3] jload_gfp+0xf3/0x105 [c01b626c] kill_node40+0x23/0x9a [c0192766] lock_carry_node_tail+0x16/0x18 [c0193f16] carry_cut+0x3f/0x4c [c019214e] carry_on_level+0x30/0xa0 [c019204a] carry+0x56/0x12a [c0196273] kill_node_content+0x123/0x13b [c019673c] cut_tree_worker_common+0x19e/0x2fe [c019659e] cut_tree_worker_common+0x0/0x2fe [c019694c] cut_tree_object+0xb0/0x14d [c0196a10] cut_tree+0x27/0x37 [c01ae0a2] extent2tail+0x1d4/0x3c0 [c014d75a] link_path_walk+0xa5/0xaf [c01aad85] find_file_item_nohint+0x2e/0x32 [c01905b3] jload_gfp+0xf3/0x105 [c0194a5f] longterm_unlock_znode+0xac/0xde [c01ac7bc] find_first_item+0x99/0xa4 [c01ac893] open_unix_file+0xcc/0xed [c01ac7c7] open_unix_file+0x0/0xed [c0141991] __dentry_open+0xb4/0x180 [c0141b33] nameidata_to_filp+0x1f/0x31 [c0141a91] do_filp_open+0x34/0x3c [c0141bd8] get_unused_fd+0x4c/0x91 [c0141cbd] do_sys_open+0x40/0xb6 [c0141d46] sys_open+0x13/0x17 [c0102397] sysenter_past_esp+0x54/0x75 Code: 24 68 8b 5c 24 6c 8b 74 24 70 89 c7 89 d5 81 c7 ff 0f 00 00 83 d5 00 25 ff 0f 00 00 89 04 24 8b 44 24 60 0f ac ef 0c 89 7c 24 08 83 78 28 00 0f 84 2b 02 00 00 89 d8 31 d2 25 ff 0f 00 00 89 c1 4reiser4[ldconfig(5748)]: release_unix_file (fs/reiser4/plugin/file/file.c:2294)[vs-44]: WARNING: out of memory? It may be related, or it may not, but here goes the history of how I got it to corrupt like that: - I recently updated to Xorg-X11 7.0 - While trying to get my wacom tablet working again, I noticed that metalog 0.8-rc1 locked up (this makes all processes that try to access the logger lock up badly on a kernel call, so I can't kill them. Gotta report this one to the metalog bugtracker) - On midst of that, I somehow accidentally killed X. But I couldn't get back to the console. - After failing to reboot the machine cleanly connecting through ssh, I tried the alt+printscreen + s - u - b method. - After reboot, I notice that a certain core lib file got truncated (how could /lib/libutil.so.1 get corrupted? This is a lib file, as many processes that were accessing it, none of them should had been writing to it!) - After hours getting a replacement file for that file and restoring glibc, I notice that the previously mentioned oops happens whenever emerge ends, when updating the ld so cache or something like that. After that, any changes to the filesystem are no longer saved. On reboot, the system is effectively restored to the point before that oops. - I can reproduce the oops whenever emerge ends, or when trying to launch a gtk2 app. The trace in both cases lead to the same file:lineno. can you install 2.6.17-mm6 and try to reproduce the problem? Sorry for the messy email format.. I am not used to mailing lists.. and I really was hoping to find/use a bugtracker instead.
Re: vanilla 2.6.17
Hello On Wed, 2006-07-05 at 14:05 +0200, jp wrote: Hi, I didn't see any follow up for my previous mail, so here's the question again : What is the status of the reiser4 patch against vanilla 2.6.17.x ? That patch will be made right after I will have fixed reiser4 bug I am working on now. Thanks JP Zenwalk.org
Re: Problem with mkreiserfs
Hello On Mon, 2006-07-03 at 10:30 +0530, Masthan, Dudekula (STSD) wrote: Hi Folks, I have a device of size 5219263 blocks (each of size of 4096, Actually it has 41754107 blocks each of size 512 bytes. I just converted it into 4k blcok). When I try to create reiserfs file system on this device it reporting ERROR message that there are no enough blocks on the device. I tried the following command #mkfs -t reiserfs -b 4096 /dev/sda1 5219263 Please let us see what do you get with echo n | mkfs -t reiserfs -b 4096 /dev/sda1 On the same device I am able to Ext2/Ext3 file system with out any problem #mkfs -t ext3 -b 4096 /dev/sda1 5219263 // this command running with out any problem. Why I am getting problem with reiserfs file system Your help is appreciated. Thanks in advance Regards Masthan
Re: reiser4 oops
Hello On Sun, 2006-07-02 at 22:24 -0600, Jake Maciejewski wrote: I'm seeing this on 2.6.16.20 with the -4 patch, amd64 with preempt. The OOM killer was called even though I have 1GB RAM and 4GB swap. My logs are available at: http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060702/oom.txt.gz Both affected filesystems (rsync was using one filesystem, cc1 the other) came up clean with fsck. On Sat, 2006-07-01 at 22:08 +0200, Łukasz Mierzwa wrote: I'm running x86 gentoo system with / on reiser4, I'm using suspend-sources-2.6.16-r8 kernel with 2.6.16-4 patch. Today I run emerge --sync, after that I started to compile new xine-lib while browsing net, when xine-lib was finishing I got this errors: kernel BUG at fs/inode.c:253! would you please check whether this patch helps? ftp://ftp.ru.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm5/broken-out/reiser4-run-truncate_inode_pages-in-reiser4_delete_inode.patch invalid opcode: [#1] PREEMPT Modules linked in: ndiswrapper fglrx acer_acpi nsc_ircc irda crc_ccitt snd_atiixp snd_ac97_codec snd_ac97_bus yenta_socket rsrc_nonstatic pcmcia_core tifm_7xx1 tifm_core CPU:0 EIP:0060:[c017bc56]Tainted: P VLI EFLAGS: 00010206 (2.6.16-suspend2-r8 #2) EIP is at clear_inode+0x16/0xb0 eax: 0003 ebx: d5245d20 ecx: edx: d5245df8 esi: df2099c0 edi: c2a3a000 ebp: c2a3a000 esp: c2a3be94 ds: 007b es: 007b ss: 0068 Process emerge (pid: 9123, threadinfo=c2a3a000 task=c2a0ba70) Stack: 0df2099c0 d5245d20 df2099c0 c01db519 c017a385 0400 d5245e28 d5245d20 c2a3a000 d415c114 d5245d20 c01db4e0 c017bd59 d5245d20 dfe9b000 c017b81c d415c114 c017a431 dfe9b000 df533000 c2a3bf50 c0172d74 Call Trace: [c01db519] reiser4_delete_inode+0x39/0xc0 [c017a385] dput+0x25/0x170 [c01db4e0] reiser4_delete_inode+0x0/0xc0 [c017bd59] generic_delete_inode+0x69/0x100 [c017b81c] iput+0x5c/0x70 [c017a431] dput+0xd1/0x170 [c0172d74] sys_renameat+0x1c4/0x1f0 [c0172dc7] sys_rename+0x27/0x30 [c0102ef3] sysenter_past_esp+0x54/0x75 Code: 80 98 00 00 00 8b 40 38 eb c4 8d 74 26 00 8d bc 27 00 00 00 00 56 53 89 c3 83 ec 04 e8 14 b0 fe ff 8b 83 c4 00 00 00 85 c0 74 08 0f 0b fd 00 ab d4 37 c0 8b 83 20 01 00 00 a8 10 75 08 0f 0b ff 4reiser4[emerge(9123)]: release_unix_file (fs/reiser4/plugin/file/file.c:2294)[vs-44]: WARNING: out of memory? reiser4[emerge(9123)]: release_unix_file (fs/reiser4/plugin/file/file.c:2294)[vs-44]: WARNING: out of memory? reiser4[emerge(9123)]: release_unix_file (fs/reiser4/plugin/file/file.c:2294)[vs-44]: WARNING: out of memory? reiser4[emerge(9123)]: release_unix_file (fs/reiser4/plugin/file/file.c:2294)[vs-44]: WARNING: out of memory? reiser4[emerge(9123)]: release_unix_file (fs/reiser4/plugin/file/file.c:2294)[vs-44]: WARNING: out of memory? reiser4[emerge(9123)]: release_unix_file (fs/reiser4/plugin/file/file.c:2294)[vs-44]: WARNING: out of memory? reiser4[emerge(9123)]: release_unix_file (fs/reiser4/plugin/file/file.c:2294)[vs-44]: WARNING: out of memory? reiser4[emerge(9123)]: release_unix_file (fs/reiser4/plugin/file/file.c:2294)[vs-44]: WARNING: out of memory? reiser4[emerge(9123)]: release_unix_file (fs/reiser4/plugin/file/file.c:2294)[vs-44]: WARNING: out of memory? reiser4[emerge(9123)]: release_unix_file (fs/reiser4/plugin/file/file.c:2294)[vs-44]: WARNING: out of memory? reiser4[emerge(9123)]: release_unix_file (fs/reiser4/plugin/file/file.c:2294)[vs-44]: WARNING: out of memory? reiser4[emerge(9123)]: release_unix_file (fs/reiser4/plugin/file/file.c:2294)[vs-44]: WARNING: out of memory? reiser4[emerge(9123)]: release_unix_file (fs/reiser4/plugin/file/file.c:2294)[vs-44]: WARNING: out of memory? reiser4[emerge(9123)]: release_unix_file (fs/reiser4/plugin/file/file.c:2294)[vs-44]: WARNING: out of memory?
Re: debugreiserfs -p contains sensitive information?
Hello On Thu, 2006-06-29 at 16:15 -0500, hanasaki wrote: debugreiserfs -p contains sensitive information? could someone from the Reiser development / design team confirm if the above command outputs any sensitive information? for example: part or all of a file on the filesystem? Just what is in the output? Looking for more details than are in the man page. debugreiserfs -p extracts metadata from a filesystem. Most of data are binary. Contents of files are not extracted. The only information which is extracted and can be considered sensitive is filenames. Having those metadata allows (usually) to reproduce reiserfsck bugs without having whole filesystem.
Re: BUG IN REISERFS
hello On Fri, 2006-06-30 at 17:51 +0530, Masthan, Dudekula (STSD) wrote: Hi Folks, Mkreiserfs command is failing by showing There are no enoguh blocks on this device , What is the minimum size of a disk to create reiserfs file system Please let us see whole mkreiserfs output and the command line itself. In case of standard journal minimal reiserfs size is 8212 blocks. Regards, Masthan
Re: ReiserFS v3 choking when free space falls below 10%?
Hello
On Thu, 2006-06-29 at 10:41 -0700, Mike Benoit wrote:
My MythTV box recently started showing odd behavior during recordings,
at certain times the load of the box would spike to 10+ and recordings
would start losing frames and become unwatchable. TOP would show
mythbackend as using 90+% SYS CPU usage, which under normal
circumstances it normally uses about 5% USR.
So I finally got around to profiling mythbackend when the load starts to
spike. To my surprise it appears that once I have less then 10% (30GB)
free on the drive reiserfs can't up, even just writing at 1mb/sec is too
much for it.
Is there something that can be done to fix this, 30gb seems like a lot
of wasted space.
#opreport
CPU: CPU with timer interrupt, speed 0 MHz (estimated)
Profiling through timer interrupt
TIMER:0|
samples| %|
--
77863 78.7856 reiserfs
18183 18.3984 vmlinux
695 0.7032 mysqld
452 0.4574 libc-2.4.so
360 0.3643 libmythtv-0.19.so.0.19.0
324 0.3278 ivtv
323 0.3268 nvidia
242 0.2449 libqt-mt.so.3.3.6
110 0.1113 libpthread-2.4.so
53 0.0536 libstdc++.so.6.0.8
35 0.0354 ld-2.4.so
23 0.0233 libperl.so
22 0.0223 libz.so.1.2.3
snip
#opreport -l /usr/src/linux/vmlinux
CPU: CPU with timer interrupt, speed 0 MHz (estimated)
Profiling through timer interrupt
samples %symbol name
9607 52.8351 default_idle
7694 42.3142 find_next_zero_bit
It looks like the problem is high fragmentation of free space.
find_next_zero_bit is a function which is used to scan bitmaps in order
to find blocks for allocation.
183 1.0064 __copy_from_user_ll
570.3135 handle_IRQ_event
370.2035 __copy_to_user_ll
340.1870 ide_outb
300.1650 ide_end_request
220.1210 ioread8
220.1210 schedule
210.1155 get_page_from_freelist
170.0935 mmx_clear_page
snip
System Details:
---
Kernel v2.6.16.21 (custom compiled)
- This issue also happened with 2.6.14 too though.
FilesystemSize Used Avail Use% Mounted on
/dev/hda1 280G 269G 12G 97% /
[EMAIL PROTECTED] cat /proc/mounts
rootfs / rootfs rw 0 0
/dev /dev tmpfs rw 0 0
/dev/root / reiserfs rw,noatime,nodiratime 0 0
[EMAIL PROTECTED] cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 6
model : 6
model name : AMD Athlon(tm) XP 2100+
stepping: 2
cpu MHz : 1759.680
cache size : 256 KB
[EMAIL PROTECTED] free
total used free sharedbuffers
cached
Mem:515992 496256 19736 0 36256
271728
-/+ buffers/cache: 188272 327720
Swap: 262136408 261728
[EMAIL PROTECTED] ~]# hdparm -i /dev/hda
/dev/hda:
Model=ST3300622A, FwRev=3.AND, SerialNo=3NF1GAGW
Config={ HardSect NotMFM HdSw15uSec Fixed DTR10Mbs RotSpdTol.5% }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
BuffType=unknown, BuffSize=16384kB, MaxMultSect=16, MultSect=16
CurCHS=4047/16/255, CurSects=16511760, LBA=yes, LBAsects=268435455
IORDY=on/off, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 udma2 udma3 udma4 *udma5
AdvancedPM=no WriteCache=enabled
Drive conforms to: Unspecified: ATA/ATAPI-1 ATA/ATAPI-2 ATA/ATAPI-3
ATA/ATAPI-4 ATA/ATAPI-5 ATA/ATAPI-6 ATA/ATAPI-7
* signifies the current active mode
[EMAIL PROTECTED] ~]# hdparm -tT /dev/hda
/dev/hda:
Timing cached reads: 1296 MB in 2.00 seconds = 646.99 MB/sec
Timing buffered disk reads: 166 MB in 3.02 seconds = 55.05 MB/sec
vmstat 1 output:
--
procs ---memory-- ---swap-- -io --system--
cpu
r b swpd free buff cache si sobibo incs us sy
id wa
8 0408 5800 29308 24860400 0 1036 406 132 2 98
0 0
4 0408 5644 29396 24860800 0 1128 437 184 2 92
0 6
7 0408 6316 29428 24802000 0 1316 539 287 0 86
0 14
5 0408 6104 29480 24818000 0 588 415 187 0 99
0 1
4 0408 5764 29536 24836400 0 1092 421 172 2 97
1 0
6 0408 6528 29592 24768400 0 1092 425 161 2 98
0 1
2 1408 6372 29676 24772400 0 2304 385 170 2 97
1 0
5 0408 6400 29676 24761600 048 383 122 0
100 0 0
7 0408 6192 29704 24787200 0 1080 409 162 1 98
0 1
6 0408 5720 29732 24830400 0 1076 414 178 1 98
0 1
7 0408 6348 29800 24755200 0 1656 460 300 2 87
1 11
5 0408 6628 29848
Re: How do deal with : rebuild-tree gives leaves all contents of which could not be,saved and deleted?
Hello On Thu, 2006-06-29 at 14:51 -0500, hanasaki wrote: Recently had to do a reboot and had not errors, just replayed transactions at reboot. Just to be safe, I rebooted into Knoppix 5.0x and did a reiserfsck which reported there were errors that needed to be fixed with --rebuild-tree The failed output of this is below. This has happened quite often and I have done a full reinstall several times. This is much more of an issue than ever was experienced with ext3 or even ext2. /// 216224 directory entries were hashed with r5 hash. r5 hash is selected Flushing..finished Read blocks (but not data blocks) 1049994 Leaves among those 44826 - corrected leaves 1 - leaves all contents of which could not be saved and deleted 3 This is only information. reiserfsck was not able to recover content of a node. Objectids found 215800 uname -a = a custom kernel from kernel.org download and build Linux deskstation 2.6.17.1hanaden #1 SMP PREEMPT Wed Jun 28 18:34:21 CDT 2006 i686 GNU/Linux Has been occurring with lower kernel numbers and those that come with both Debian and Ubuntu
Re: ReiserFS v3 choking when free space falls below 10%?
Hello On Thu, 2006-06-29 at 13:15 -0700, Mike Benoit wrote: On Thu, 2006-06-29 at 23:12 +0400, Vladimir V. Saveliev wrote: Hello On Thu, 2006-06-29 at 10:41 -0700, Mike Benoit wrote: So I finally got around to profiling mythbackend when the load starts to spike. To my surprise it appears that once I have less then 10% (30GB) free on the drive reiserfs can't up, even just writing at 1mb/sec is too much for it. Is there something that can be done to fix this, 30gb seems like a lot of wasted space. #opreport CPU: CPU with timer interrupt, speed 0 MHz (estimated) Profiling through timer interrupt TIMER:0| samples| %| -- 77863 78.7856 reiserfs 18183 18.3984 vmlinux 695 0.7032 mysqld 452 0.4574 libc-2.4.so 360 0.3643 libmythtv-0.19.so.0.19.0 324 0.3278 ivtv 323 0.3268 nvidia 242 0.2449 libqt-mt.so.3.3.6 110 0.1113 libpthread-2.4.so 53 0.0536 libstdc++.so.6.0.8 35 0.0354 ld-2.4.so 23 0.0233 libperl.so 22 0.0223 libz.so.1.2.3 snip #opreport -l /usr/src/linux/vmlinux CPU: CPU with timer interrupt, speed 0 MHz (estimated) Profiling through timer interrupt samples %symbol name 9607 52.8351 default_idle 7694 42.3142 find_next_zero_bit It looks like the problem is high fragmentation of free space. find_next_zero_bit is a function which is used to scan bitmaps in order to find blocks for allocation. This seems strange, because to me this type of workload would lend itself to being less fragmented then most workloads. All the box does is records TV programs, so over the course of 30-60min periods I would guess 95+% of the writes are sequential. do you ever remove files? Why would the fragmentation be so bad? Is there a way to tell what the fragmentation rate is? can you please run debugreiserfs -m /dev/hda1 bitmap and send me that file? bitmap should contain dump of free and used blocks. If most of bitmap blocks contain a lot of interleaving free/used sections - free space is highly fragmented and allocating new free blocks can be CPU expensive. Thanks.
Re: [PATCH] reiserfs:fix journaling issue regarding fsync()
Hello
Sorry, but afaics reiserfs' fsync works as it is supposed to.
I experiment with the attached program. After reboot I make sure that
file has new file size.
On Tue, 2006-06-20 at 17:43 +0900, Hisashi Hifumi wrote:
Hi,
When write() extends a file(i_size is increased) and fsync() is
called, change of inode must be written to journaling area
through fsync().
But,currently the i_trans_id is not correctly updated when i_size
is increased. So fsync() does not kick the journal writer.
Following patch fix this bug.
Signed-off-by :Hisashi Hifumi [EMAIL PROTECTED]
diff -Nru linux-2.6.17/fs/reiserfs/super.c
linux-2.6.17_fix/fs/reiserfs/super.c
--- linux-2.6.17/fs/reiserfs/super.c 2006-06-18 10:49:35.0 +0900
+++ linux-2.6.17_fix/fs/reiserfs/super.c 2006-06-20 14:38:28.0
+0900
@@ -558,6 +558,7 @@
reiserfs_write_unlock(inode-i_sb);
return;
}
+ reiserfs_update_inode_transaction(inode);
reiserfs_update_sd(th, inode);
journal_end(th, inode-i_sb, 1);
reiserfs_write_unlock(inode-i_sb);
Thanks,
#include stdio.h
#include fcntl.h
#include sys/stat.h
int main(int argc, char **argv)
{
int fd;
struct stat st;
fd = open(argv[1], O_WRONLY | O_APPEND);
if (fd == -1) {
perror(open failed);
return 0;
}
if (fstat(fd, st)) {
perror(stat failed);
return 0;
}
printf(old file size %d\n, st.st_size);
if (write(fd, hello, 5) != 5) {
perror(write failed);
return 0;
}
if (fstat(fd, st)) {
perror(stat failed);
return 0;
}
printf(new file size %d\n, st.st_size);
if (fsync(fd)) {
perror(fsync failed);
return 0;
}
printf(rebooting); fflush(stdout);
system(reboot -f -n);
return 0;
}
Re: Try to fix a broken ReiserFS / Data Recovering?
Hello On Tue, 2006-06-20 at 12:14 +0200, Lars Wolff wrote: Hi List, hi Vladimir! _My Questions_ - Am i right in doing these actions to try to resolve the problem of my harddisk, and HOPEFULLY to recover the Data? after dd_rescue completes - please run reiserfsck (3.6.19, without any options but filename) on backup image and let us know what it says. i did i as explained here: http://martian.org/marty/2003/09/05/reiserfs-filesystem-recovery Yesterday night reiserfsck finished up clear and i could mount the dd_rescue_imag on a loopdevice and at least to the filesystem : I took the whole night to copy all data, but i alreade found everthing, i also got some files in lost+found and have to check this manually. Do Somebody now a easy way to work with the lost+found files? (X_y X=inode right?) Real names of files of directories which got into lost+found are lost. Instead X_y are generated. X is inode number of a directory in which file was created. y is inode number of file. If X_y is a directory - files below (if any) have their normal names. For each of X_y you may try to find a directory with inode number X (find -inum X). If such directory exists - it is possible that X_y belongs to it. And, use file(1) for binary files. Lars
Re: Try to fix a broken ReiserFS / Data Recovering?
Hello On Mon, 2006-06-19 at 11:28 +0200, Lars Wolff wrote: Hi there, i am very new to this list, i just signed up today, because i got some problems with a broken ReiserFS since yesterday. _The problem_ Yesterday my Router/Server (Suse Linux 8.1, 40GB IDE HDD with ReiserFS) hang up. After a reboot it only starts to load stage2 of Grub, which fails and ends up in the grub minimal bash. _What i do to resolve the problem_ I downloaded the Suse Live-CD 9.1 and did a clean boot from it. I Try to mount the volume, what end up with Falscher Dateisystemtyp, ungültige Optionen, der »Superblock« von /dev/hdb2 ist beschädigt oder es sind zu viele Dateisysteme eingehängt (=corrupt superblock) Then I tried reiserFs Check wich ends up in: Bad root block 0. (--rebuild-tree did not complete). Ok, i followed the instructions in the following bad block info text and did a reiserFs -B badblocksfile --rebuild-tree. Wich aborts and said badblock in . Right now i am doing a complete Backup image with dd_rescue, after this i would like to run /sbin/badblocks, as explained in the Faq (http://www.namesys.com/bad-block-handling.html) and run then reiserfs -B again. _My Questions_ - Am i right in doing these actions to try to resolve the problem of my harddisk, and HOPEFULLY to recover the Data? after dd_rescue completes - please run reiserfsck (3.6.19, without any options but filename) on backup image and let us know what it says. - Is there anything i should try/do else? - Do you now somebody/any company, wich do a real data-recovering von ReiserFS Disk? Its only 40GB but there are some data on it wich are very important. (don't ask after the backups, they broke last week on the extern hdd! :(( ) Hopefully you guys can help me, thanks a lot :) Lars
Re: BUG: reiserfsck --check fails exit status=6
Hello On Mon, 2006-06-19 at 14:50 +0530, Masthan, Dudekula (STSD) wrote: Hi, I am using SUSE 10 beta version. I ran reiserfsck command with the following options reiserfsck --check -q -y -n /dev/sdb1 21 O/p of the command look like this. reiserfsck 3.6.19 (2003 www.namesys.com) * If you are using the latest reiserfsprogs and it fails ** * please email bug reports to reiserfs-list@namesys.com, ** * providing as much information as possible -- your ** * hardware, kernel, patches, settings, all reiserfsck ** * messages (including version), the reiserfsck logfile, ** * check the syslog file for any related information. ** * If you would like advice on using this program, support ** * is available for $25 at www.namesys.com/support.html. ** * Will read-only check consistency of the filesystem on /dev/sdb1 Will put log info to 'stdout' reiserfsck --check started at Mon May 29 13:16:40 2006 Relaying journal.. Reiserfs journal '/dev/sdb1' in blocks [18..8211]: 0 transactions replayed checking internal tree..finished Comparing bitmaps..Checking Semantic tree: finished 26 found corruptions can be fixed when running with --fix-fixable reiserfsck finished at Mon May 29 13:16:44 2006 reiserfsck exit status = 6 Can any one Explain this .. reiserfsck has 3 major modes. By default (or with --check) it checks filesystem and either says that everything is ok, or reiserfsck has to be run with --fix-fixable (when filesystem can be fixed without tree rebuiling) or with --rebuild-tree when corruptions can be recovered only via complete tree rebuild. Why it happened ? Can you re-run reiserfsck --check without -n and with -l logfile and let us see what you get in logfile? Your help is appreciated Regards, Masthan
Re: reiserfschk --rebuild-tree was aborted, said disk was full
Hello On Thu, 2006-06-15 at 09:15 +0200, Johan Isacsson wrote: reiserfschk --rebuild-tree was aborted when it nearly had finished pass 1 and now i can't mount the partition. I no longer have the exact error message. Just before the filesystem got bad we had removed lots of data because the disk got full. Df then reported that there was lots of space left on that partition. After that we had to power cycle the server because it got hung up and after the reboot df reborted 100% usage and that some files couldn't be read. I den did a reiserfschk --check which said there wer fatal errors and that i needed to do a rebuild-tree, which i did. And after a long while it was aborted at about 90% of pass 1. I have the version 3.6.19-2 of reiserfs-progs (FC 4). Of course i read about taking a backup after i had done the --rebuild-tree :( Please, let us see complete reiserfsck --rebuild-tree output.
Re: reiserfschk --rebuild-tree was aborted, said disk was full
Hello On Thu, 2006-06-15 at 11:28 +0200, Johan Isacsson wrote: Hello, Unfortunately that output was not logged and it will take a couple of hours to do a new check and get the output, but besides the specific numbers in the following output which i found (after posting my help request) in the mailing list archive the message i got was this: [snip] Pass 0: Loading on-disk bitmap .. ok, 61048992 blocks marked used Skipping 10074 blocks (super block, journal, bitmaps) 61038918 blocks will be read 0%20%40%60%.. lef \ left 0, 13223 /secccsec r5 hash is selected Flushing..finished Read blocks (but not data blocks) 61038918 Leaves among those 141109 - leaves all contents of which could not be saved and deleted \ 5 Objectids found 414533 Pass 1 (will try to insert 141104 leaves): Looking for allocable blocks .. finished 0%20%40%60%80%Not enough allocable blocks, checking \ bitmap...there are 1 allocable blocks, btw out of disk space Aborted [/snip] So i guess i should do as you replied to the person posting this and do a dd to a bigger partition and do the rebuild-tree there? Here is the reply to the older post: [snip] you need to get a larger partition, dd hdg1 there, run 'reiserfsck --rebuild-sb' on the copy to enlarge the fs size and after that run 'reiserfsck --rebuild-tree' on it. or you can enlarge the existent hdg1. Note: some disk space will be added to the current partition, if there was a reiserfs before, that fs metadata will be mixed with the current fs. to avoid it, zero the added disk space first (dd if=/dev/zero ...) [/snip] I don't get the last part, if i do this and it works well i end up with an OK file system on the other partition, should i completely wipe the old partition before i dd it back to avoid problems? dd if=/dev/zero of=/dev/oldpart? no You copied oldpart to bigger newpart. End of newpart which was not overwritten by oldpart should be zeroed. Keep oldpart intact until you have data restored on newpart. Do you think there's any hope getting my data back? yes Thanks for replying! /Johan Vladimir V. Saveliev skrev: Hello On Thu, 2006-06-15 at 09:15 +0200, Johan Isacsson wrote: reiserfschk --rebuild-tree was aborted when it nearly had finished pass 1 and now i can't mount the partition. I no longer have the exact error message. Just before the filesystem got bad we had removed lots of data because the disk got full. Df then reported that there was lots of space left on that partition. After that we had to power cycle the server because it got hung up and after the reboot df reborted 100% usage and that some files couldn't be read. I den did a reiserfschk --check which said there wer fatal errors and that i needed to do a rebuild-tree, which i did. And after a long while it was aborted at about 90% of pass 1. I have the version 3.6.19-2 of reiserfs-progs (FC 4). Of course i read about taking a backup after i had done the --rebuild-tree :( Please, let us see complete reiserfsck --rebuild-tree output.
Re: [PATCH] updated reiser4 - reduced cpu usage for writes by writing more than 4k at a time (has implications for generic write code and eventually for the IO layer)
Hello On Thu, 2006-06-08 at 13:00 +0200, Jens Axboe wrote: On Wed, May 24 2006, Hans Reiser wrote: Tom Vier wrote: On Tue, May 23, 2006 at 01:14:54PM -0700, Hans Reiser wrote: underlying FS can be improved. Performance results show that the new code consumes 40% less CPU when doing dd bs=1MB . (your hardware, and whether the data is in cache, may vary this result). Note that this has only a small effect on elapsed time for most hardware. Write requests in linux are restricted to one page? It may go to the kernel as a 64MB write, but VFS sends it to the FS as 64MB/4k separate 4k writes. Nonsense, Hans refers to generic_file_write which does prepare_write copy_from_user commit_write for each page. there are ways to get PAGE_CACHE_SIZE writes in one chunk. Other file systems have been doing it for years. Would you, please, say more about it.
Re: [PATCH] updated reiser4 - reduced cpu usage for writes by writing more than 4k at a time (has implications for generic write code and eventually for the IO layer)
Hello On Thu, 2006-06-08 at 13:35 +0200, Jens Axboe wrote: On Thu, Jun 08 2006, Vladimir V. Saveliev wrote: Hello On Thu, 2006-06-08 at 13:00 +0200, Jens Axboe wrote: On Wed, May 24 2006, Hans Reiser wrote: Tom Vier wrote: On Tue, May 23, 2006 at 01:14:54PM -0700, Hans Reiser wrote: underlying FS can be improved. Performance results show that the new code consumes 40% less CPU when doing dd bs=1MB . (your hardware, and whether the data is in cache, may vary this result). Note that this has only a small effect on elapsed time for most hardware. Write requests in linux are restricted to one page? It may go to the kernel as a 64MB write, but VFS sends it to the FS as 64MB/4k separate 4k writes. Nonsense, Hans refers to generic_file_write which does prepare_write copy_from_user commit_write for each page. Provide your own f_op-write() ? Yes, a filesystem can do that. But it is more welcomed to kernel if it writes/reads using generic functions. there are ways to get PAGE_CACHE_SIZE writes in one chunk. Other file systems have been doing it for years. Would you, please, say more about it. Use writepages? This is about flushing, not sys_write.
Re: [PATCH] updated reiser4 - reduced cpu usage for writes by writing more than 4k at a time (has implications for generic write code and eventually for the IO layer)
Hello On Thu, 2006-06-08 at 12:45 +0200, Jan Engelhardt wrote: I'm actively using Reiser4 on a production servers (and I know a lot of people that do that too). Could you please release the patch against the vanilla tree? I don't think there's a lot of people that will test -mm version, especially on production servers - -mm is a little bit too unstable. Any chance to get this patch against 2.6.17-rc4-mm3? yes, reiser4 updates for latest stock and mm kernels will be out in one or two days There is a version out for 2.6.17-rc4-mm1, but for stock kernel? Has the latter been canceled? There is quite fresh ftp://ftp.namesys.com/pub/reiser4-for-2.6/2.6.16/reiser4-for-2.6.16-4.patch.gz Jan Engelhardt
Re: reiser4: first impression (vs xfs and jfs)
Hello On Tue, 2006-06-06 at 09:44 -0400, Tom Vier wrote: On Tue, May 23, 2006 at 11:51:02AM -0400, Tom Vier wrote: It seems that both r4 and xfs allow a large number of pages to be dirtied, before queuing them for writeback, and this has a negative effect on throughput. In my test (rsync'ing ~50gigs of flacs), r4 and xfs are almost 10 minutes slower than jfs. Just to follow up on this (i've been too busy lately), that's how delayed allocation works. It waits til the vm forces writeouts. In my case of copying large files from a slower drive, the delayed allocation of r4 and xfs is stalling reads from the source, since neither will write until the vw forces it. Is there a way in r4 to force sync a mount every so often, ala flushd? reiser4 has an option for that. mount -o tmgr.atom_max_age=N N is decimal number of seconds. Changes older than N will be forced to commit. ext3 has the commit option. Does r4 have a hard coded sync timer already? If not, i think it's an important feature that should be added (and made a mount option). Otherwise, a lot of data can be lost. Does the kernel do a system wide sync every 30sec, like it used to?
Re: ReiserFS slow, need help diagnosing
Hello On Mon, 2006-06-05 at 15:11 +0200, Juergen Starek wrote: Hello everyone, I hope this is the right mailing list for my question, if not, please redirect me. I have noticed that if I put my ~ on a ReiserFS partition, Pan (GNOME's newsreader) starts very slowly, taking about 75 seconds. If I move the same article cache onto an ext3 partition, Pan starts in less than 10 seconds. This confuses me, as I've read a lot of benchmarks and comments on the net which indicate that ReiserFS is faster than ext3 when handling lots of small files. Pan's article cache consists of lots of small files (approx. 70 MB, each file has only a few kilobytes) and, on my system, it should not be fragmented too much because I copied the files from an external source onto the empty volume. Probably Pan is stat(2)-ing whole cache. Can you please try to find out what Pan is doing on start? Strace(1) may help. If Pan is doing millions of stats for files from cache - that explains why it starts slowly when cache is stored on reiserfs. Asking this question on the German Linux newsgroup de.comp.os.unix.linux.misc[1] didn't lead to any hints about diagnosing this behaviour. Any ideas? Many thanks in advance Jürgen [1] http://groups.google.de/group/de.comp.os.unix.linux.misc/browse_thread/thread/d60014be503abebd/
Re: ReiserFS slow, need help diagnosing
Hello
On Mon, 2006-06-05 at 16:29 +0200, Juergen Starek wrote:
Vladimir V. Saveliev schrieb:
On Mon, 2006-06-05 at 15:11 +0200, Juergen Starek wrote:
I have noticed that if I put my ~ on a ReiserFS partition, Pan (GNOME's
newsreader) starts very slowly, [...]
Probably Pan is stat(2)-ing whole cache. Can you please try to find out
what Pan is doing on start? Strace(1) may help.
You're right, I straced Pan's start process and after initialization, it
seems to call stat64 on every message in its cache. This is a snippet of
the trace, produced on an ext3 filesystem (line length exceeds 80 chars):
==
stat64(/home/jstarek/.pan/gmane, {st_mode=S_IFDIR|0755, st_size=4096, ...})
= 0
stat64(/home/jstarek/.pan/Standard, {st_mode=S_IFDIR|0755, st_size=4096,
...}) = 0
stat64(/home/jstarek/.pan/messages/cache, {st_mode=S_IFDIR|0755,
st_size=1032192, ...}) = 0
open(/home/jstarek/.pan/messages/cache,
O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 6
fstat64(6, {st_mode=S_IFDIR|0755, st_size=1032192, ...}) = 0
fcntl64(6, F_SETFD, FD_CLOEXEC) = 0
getdents64(6, /* 62 entries */, 4096) = 4096
stat64(/home/jstarek/.pan/messages/cache/[EMAIL PROTECTED],
{st_mode=S_IFREG|0644, st_size=1426, ...}) = 0
time(NULL) = 1149517138
==
The last two calls of this trace snippet are then repeated for all files
in the cache.
If Pan is doing millions of stats for files from cache - that explains
why it starts slowly when cache is stored on reiserfs.
Could you please explain this? An URL with the explanation is fine, too --
I just don't have experience with file systems...
reiserfs does not store inodes as compact as ext3. It allocates inodes
dynamically. As result reiserfs inodes get spread over whole filesystem.
Also reiserfs tries to store file bodies in the same block as file's
inode. As result one reiserfs block usually contains inodes than ext[23]
inode block does.
So, to stat each file of directory reiserfs has to perform more disk
reads and to do more disk head seek than a filesystem which stores
inodes compactly in preallocated disk area.
Thanks,
Jürgen
Re: ReiserFS slow, need help diagnosing
Hello On Mon, 2006-06-05 at 17:34 +0200, Grzegorz Kulewski wrote: On Mon, 5 Jun 2006, Vladimir V. Saveliev wrote: reiserfs does not store inodes as compact as ext3. It allocates inodes dynamically. As result reiserfs inodes get spread over whole filesystem. Also reiserfs tries to store file bodies in the same block as file's inode. As result one reiserfs block usually contains inodes than ext[23] inode block does. So, to stat each file of directory reiserfs has to perform more disk reads and to do more disk head seek than a filesystem which stores inodes compactly in preallocated disk area. Is this performance problem with stat heavy load fixed in Reiser4? Well, inode location in reiser4 changed comparing to reiserfs. reiser4 groups inodes of files of one directory together (reiserfs did not do that), but still allocated disk space for inodes dynamically as reiserfs. So, I guess that reiser4 will be better than reiserfs, but still worse than ext[23]. Would you verify this guess it please? Thanks, Grzegorz Kulewski
Re: reiser4 for 2.6.16 (version 3)
Hello On Tue, 2006-05-30 at 17:49 +0400, [EMAIL PROTECTED] wrote: #cd /usr/src/linux-std #make clean #gzip -dc ../reiser4-for-2.6.16-3.patch.gz | patch -p1 --silent #make all #make modules_install ---cut--- if [ -r System.map -a -x /sbin/depmod ]; then /sbin/depmod -ae -F System.map 2.6.16.18; fi WARNING: /lib/modules/2.6.16.18/kernel/fs/reiser4/reiser4.ko needs unknown symbol balance_dirty_pages WARNING: /lib/modules/2.6.16.18/kernel/fs/reiser4/reiser4.ko needs unknown symbol page_cache_readahead make: *** [_modinst_post] Ошибка 1 thanks, please try that ftp://ftp.namesys.com/pub/reiser4-for-2.6/2.6.16/reiser4-for-2.6.16-4.patch.gz # uname -a Linux losthold.vs 2.6.16.18 #12 PREEMPT Mon May 29 21:43:25 MSD 2006 i686 AMD Athlon(tm) unknown GNU/Linux # gcc -v Using built-in specs. Target: i586-mandriva-linux-gnu Configured with: ../configure --prefix=/usr --libexecdir=/usr/lib --with-slibdir=/lib --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --enable-languages=c,c++,ada,f95,objc,java --host=i586-mandriva-linux-gnu --with-system-zlib --enable-long-long --enable-__cxa_atexit --enable-clocale=gnu --disable-libunwind-exceptions --enable-java-awt=gtk --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --enable-gtk-cairo --disable-libjava-multilib Thread model: posix gcc version 4.0.1 (4.0.1-5mdk for Mandriva Linux release 2006.0) reiser4-for-2.6.16-2.patch.gz -- compile and install without this problem. On Tue, 30 May 2006 15:54:35 +0400 Alexander Zarochentsev [EMAIL PROTECTED] wrote: On Monday 29 May 2006 21:30, Vladimir V. Saveliev wrote: Hello ftp://ftp.namesys.com/pub/reiser4-for-2.6/2.6.16/reiser4-for-2.6.16-3 .patch.gz contains the most recent reiser4 code which is considered stable inside Namesys. This code is supposed to be in mm kernel next to 2.6.17-rc4-mm3. Please try it. Any feedback is welcome. it works on the Cuba server. uptime is 3:54pm up 5:25, 2 users, load average: 0,00, 0,00, 0,00 -- Alex. A. -- Hic Jacet Ego
Re: RAID-1 and Reiser4 issue: umount hangs
Hello On Mon, 2006-05-29 at 22:17 +0200, Arend Freije wrote: Hi, I'm using Reiser4 for my filesystems on disk (/dev/sda) , and it works just fine. Recently I bought a second disk (/dev/sdb) for RAID-1 mirroring. With mdadm I created a degraded raid-1 array on /dev/md/0, devices missing,/dev/sdb1. After that I created a Reiser4 filesystem on /dev/md/0 and mounted it at /mnt. Then I copied the data from /dev/sda1 to /mnt. All goes well until I umount /mnt, umount simply hangs without any error. Syslog doesn't report any error. In /proc/mdstat, the array remains active sync. Shutting down linux fails because the umount is still waiting and seems to block other umounts. The umount process cannot be killed by the root. A hard reset is the only resolution to get my system functioning normally, but without the raid-1 of course. The problem seems to emerge only with the combination of RAID and Reiser4. I've created an ext-2 filesystem on /dev/md/0, and after that mount ; cp -ax ; umount works without a problem, and the hanging umount re-appears when using Reiser4 again. My questions: - how can I find the cause of the hanging umount? - how can I fix it? A few details of my linux-box: Gentoo Linux, 2.6.16 kernel with Reiser4-for-2.6.16-2.patch.gz Would you please try whether ftp://ftp.namesys.com/pub/reiser4-for-2.6/2.6.16/reiser4-for-2.6.16-4.patch.gz has the same problem? i686 AMD Athlon(tm) XP 2400+ DC4300 SATA-II controller (Silicon Image 3124, libata + sata_sil24 drivers) 2 x Samsung SP2504C hard disk I've posted this issue to the linux-kernel mailing list, but Neil Brown wrote: This looks very much like a reiser4 problem rather than a raid problem, or at least you will need someone very familiar with reiser4 to understand what is going on here. So here's my post. The call trace of the hanging umount is the following: syslog-ng R running 0 7581 17197 (NOTLB) umountD C011B591 0 7588 7200 (NOTLB) f6643c98 c1808320 c011b591 f7db5ad0 f4d18c00 003d092a f7db5ad0 c1808320 f4d18c00 003d092a f6b33540 c1808320 f4d18c00 003d092a f6b33540 f6b33668 c1808320 f6643cfc Call Trace: [c011b591] __wake_up_common+0x41/0x70 [c0318346] io_schedule+0x26/0x30 [c01469fb] sync_page+0x4b/0x60 [c03184d5] __wait_on_bit+0x45/0x70 [c01469b0] sync_page+0x0/0x60 [c014726d] wait_on_page_bit+0xad/0xc0 [c0136a30] wake_bit_function+0x0/0x60 [c0136a30] wake_bit_function+0x0/0x60 [c01ac2f9] jwait_io+0x59/0x80 [c01c1763] update_journal_header+0x83/0xb0 [c01c272a] commit_tx+0xca/0x110 [c01c29a1] reiser4_write_logs+0x141/0x1e0 [c01b9d91] commit_current_atom+0x171/0x2c0 [c01baabf] try_commit_txnh+0x13f/0x1e0 [c01bab94] commit_txnh+0x34/0xd0 [c01b91bc] txn_end+0x2c/0x30 [c01b91d0] txn_restart+0x10/0x30 [c01b920a] txn_restart_current+0x1a/0x20 [c01b9f1f] force_commit_atom+0x3f/0x70 [c01ba03a] txnmgr_force_commit_all+0xea/0x130 [c01fcb0e] release_format40+0x7e/0x150 [c01b5ea8] init_context+0x58/0x80 [c01c8b89] reiser4_put_super+0x89/0xf0 [c01857ed] invalidate_inodes+0x5d/0x80 [c0170fb6] generic_shutdown_super+0x156/0x160 [c0171b2d] kill_block_super+0x2d/0x50 [c0170d90] deactivate_super+0x60/0x80 [c0188e1f] sys_umount+0x3f/0x90 [c01171b0] do_page_fault+0x1c0/0x5a8 [c0159bc1] sys_munmap+0x51/0x80 [c0188e87] sys_oldumount+0x17/0x20 [c010306b] sysenter_past_esp+0x54/0x75 Thanx in advance, Arend
reiser4 for 2.6.16 (version 3)
Hello ftp://ftp.namesys.com/pub/reiser4-for-2.6/2.6.16/reiser4-for-2.6.16-3.patch.gz contains the most recent reiser4 code which is considered stable inside Namesys. This code is supposed to be in mm kernel next to 2.6.17-rc4-mm3. Please try it. Any feedback is welcome.
Re: reiser4progs+libaal 1.0.5
Hello On Thu, 2006-05-25 at 21:18 +0400, [EMAIL PROTECTED] wrote: Hi all! I have same problem, as at topic http://www.nabble.com/reiser4progs+1.0.5+configure+script+and+libaal+1.0.5-t221999.html The reiser4progs 1.0.5 can't find libaal 1.0.5, which installed in /usr/local ls /usr/local/lib/libaal* ? (this path is in /etc/ld.so.conf and ldconfig was made) checking for aal_device_open in -laal... yes checking aal/libaal.h usability... yes checking aal/libaal.h presence... yes checking for aal/libaal.h... yes checking for libaal version = 1.0.5... no But glibc not 2.3.2, as in that case. # rpm -qa | grep glibc glibc-2.3.5-5mdk glibc-devel-2.3.5-5mdk distro - Mandriva 2006 (kernel 2.6.16.18) How can I trace an error? Any help would be appreciated... Thank you. A. -- Hic Jacet Ego
Re: [PATCH] updated reiser4 - reduced cpu usage for writes by writing more than 4k at a time (has implications for generic write code and eventually for the IO layer)
Hello On Tue, 2006-05-23 at 22:33 +0200, Michal Piotrowski wrote: Hi Hans, On 23/05/06, Alexey Polyakov [EMAIL PROTECTED] wrote: Hi! I'm actively using Reiser4 on a production servers (and I know a lot of people that do that too). Could you please release the patch against the vanilla tree? I don't think there's a lot of people that will test -mm version, especially on production servers - -mm is a little bit too unstable. Any chance to get this patch against 2.6.17-rc4-mm3? yes, reiser4 updates for latest stock and mm kernels will be out in one or two days Regards, Michal
Re: quicker mount
Hello On Tue, 2006-05-23 at 10:43 -0400, Tom Vier wrote: What about reiserfs4? I just tried a 250gig raid1 and it r4 takes even longer than 3. Is it also preloading all bitmaps? No other fs that i've tried takes so long to mount. reiser4 has mount option for that. please try mount -o dont_load_bitmap
