Re: Reiser4: Running out of room still causes corruption
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. I was able to reproduce this error and log the oops: 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 [8031a305] reiser4_grab_space+0x45/0xa0 Oct 16 01:04:23 Theben [8031a5ea] reiser4_grab_reserved+0xaa/0x170 Oct 16 01:04:23 Theben [803340fe] cut_file_items+0x12e/0x1d0 Oct 16 01:04:23 Theben [80335020] update_file_size+0x0/0x90
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
[2.6.19-rc2-mm1] error: too few arguments to function ‘crypto_alloc_hash’
Hello, The latest -mm introduced a new error: CC fs/reiser4/plugin/crypto/digest.o fs/reiser4/plugin/crypto/digest.c: In function ‘alloc_sha256’: fs/reiser4/plugin/crypto/digest.c:17: error: too few arguments to function ‘crypto_alloc_hash’ make[2]: *** [fs/reiser4/plugin/crypto/digest.o] Error 1 make[1]: *** [fs/reiser4] Error 2 make: *** [fs] Error 2 Andrew Wade
Re: Which version will be merged into mainline kernel?
Hi again and thanks for the response, Will reiser-4.0 or reiser-4.1 be merged into mainline kernel, I ask I don't know, why it should be merged partially. I.e. all or nothing. I thought that compression belongs exclusivly to reiser4-4.1, and maybe because of stability issues only reiser4-4.0 will maybe merged. Great to hear to maybe soon get the full power at once :-) If you want to try out in the latest -mm kernel, then we will send you the setup. I am currently really busy - I've just started university. But I would be happy if I would be allowed to ask for help again in a few weeks :-) Btw. Is there anything new about includion into mainline? I read somewhere that first 2.6.19 was the goal but now it is 20 or 21. Is it now more or less a predictable thing, only when exactly is still open or can kernel devs still change their opinion? lg Clemens
Re: Which version will be merged into mainline kernel?
Hello Clemens, Tuesday, October 17, 2006, 11:14:33 PM, you wrote: somewhere that first 2.6.19 was the goal but now it is 20 or 21. Is it now more or less a predictable thing, only when exactly is still open or can kernel devs still change their opinion? It is largely up to Andrew Morton. I trust him and I think that when he says r4 is ready, it is ready. Andrew keeps knows that there are both sides of the story here and he does his best to push r4 into mainline while keeping to it that the code adhers to requirements and guidelines stated by kernel developers. I belive r4 is soon to be merged, if not in december/january then surely before easter. (would be a good xmas present,hehe) Regards, Maciej
Re: CFP: Linux 2007 File System IO Workshop
On Mon, 2006-10-16 at 20:40 -0400, Ric Wheeler wrote: On February 12-13, we have put together a combined Linux file system IO 2-day workshop in San Jose, CA. Note that the USENIX File System and Storage Technologies conference follows us in the same venue, so we hope to get some interaction between the two groups as well as leverage the USENIX people to help us get this done. For more information, please see: http://www.usenix.org/events/lsf07/ Just to clarify, this event is a follow on to the Vancouver Storage summit. Although USENIX is helping us to run it, you don't have to be a USENIX member to submit a position paper. The idea of the position papers is to give the limited number of places (for storage we've got about 20-25 and about the same again for fs) to people who have interesting topics they need to discuss---so if you submit, be prepared to make a presentation of it. James
Re: CFP: Linux 2007 File System IO Workshop
--- James Bottomley [EMAIL PROTECTED] wrote: On Mon, 2006-10-16 at 20:40 -0400, Ric Wheeler wrote: On February 12-13, we have put together a combined Linux file system IO 2-day workshop in San Jose, CA. Note that the USENIX File System and Storage Technologies conference follows us in the same venue, so we hope to get some interaction between the two groups as well as leverage the USENIX people to help us get this done. For more information, please see: http://www.usenix.org/events/lsf07/ Just to clarify, this event is a follow on to the Vancouver Storage summit. The only mentioning of Vancouver Storage summit in the web content therein was, quoting from http://www.usenix.org/events/lsf07/cfp/ : ... * Progress reports on implementation of features discussed at the Vancouver Storage Summit ... So by follow on you mean progress report only? Or will this event also accept and/or discuss new material? Although USENIX is helping us to run it, you don't have to be a USENIX member to submit a position paper. The idea of the position papers is to give the limited number of places (for storage we've got about 20-25 and about the same again for fs) to people who have interesting topics they need to discuss---so if you submit, be prepared to make a presentation of it. Can I make a presentation of this paper: Serial Attached SCSI, An Architecture For Linux - This paper would start with an overview of SCSI (SCSI-3, that is), its object oriented nature and why such is the direction of SCSI. Then an introduction to SAS from this SCSI point of view will be given, i.e. where it fits in the object oriented model, why and how. There may be very little SAS technical introduction--a couple of sentences, something anyone would understand and something sufficient for the latter sections of the paper. Then an introduction to SAS as an architecture in a SCSI stack would follow. A layered, object oriented model will be presented, similar to the one found in my code. This will be accompanied with a SCSI architectural roadmap, the how and why the architecture. Then an overview of pure-SCSI drivers would be given (at this point the paper talks about implementations at each layer of the storage software stack). Those are implementations which hide the transport layer completely in their firmware, and present a pure SCSI picture, a la SAM, to the OS. How and why they do it and why it is better. Then the paper would talk about what unifies those implementations, how it can be done, and why it should be done this way. An introduction to SDI, SCSI Driver Interface, would be presented. There would be a section on a SCSI/ATA Translation, SAT, and a SAT Layer (SATL). Where it fits, how and why. What its interface is and why. The paper would include pictures and figures as necessary to show layers, object oriented concepts and the like. The thread is here: http://marc.theaimsgroup.com/?t=11419758022r=1w=2 Luben
Re: CFP: Linux 2007 File System IO Workshop
--- James Bottomley [EMAIL PROTECTED] wrote: You can submit it as your position paper, certainly. It is not a position paper. There is too much SCSI Architecture Model (SAM) in it. But from linux-scsi point of view I guess it is. However, the object of this event is not to collect a list of papers to be presented: it's not a conference with hundreds of attendees (if you want to present to an audience, you should submit to FAST, which is such a conference, with which we're co-located). It's a roundtable type discussion with 20-25 people in the field; plus some plenary sessions to get input and ideas from people working on the filesystem layer. The object is to stimulate discussion of important issues (which may be guided by papers or other materials). The position paper thing is only to ensure people actually have things they want to discuss (and to allow the programme committee to pick the attendees if there would be too many). Ok, so this is targeted at the same 20-25 Linux people who attended the Vancouver Storage summit and you're just using FAST to co-locate. I incorrectly assumed that this was targeted at storage professionals not necessarily Linux related, but with Linux exposure so as to hear new ideas and pathways. I also missed to see the by-invitation clause at the top. Thanks for the explanation! Luben
