* Oops with large file in 2.6.8, reiser 3.6.13
@ 2004-10-19 12:28 Richard Gregory
2004-10-24 8:37 ` Alex Zarochentsev
0 siblings, 1 reply; 6+ messages in thread
From: Richard Gregory @ 2004-10-19 12:28 UTC (permalink / raw)
To: reiserfs-list
Have managed to create an Oops in the reiser code, dmesg output below.
This was on a software raid5 setup, with 8 160Gb disks, creating around
1.1Tb of storage. There was around 400Gb of content on this filesystem,
then as an over night test, /dev/zero was dd'ed to a file on the
filesystem, creating an approx 720Gb file and filling the filesystem.
The problem came when I tried to delete it, rm'ing it caused an Oops in
the reiser code. The system was rebooted, but mounting the filesystem
gave the oops below.
Am currently running reiserfsck --check to see if this file can be
removed some other way, otherwise, it will mean a very long reformat and
copy operation.
Something else, this filesystem had recently been resized from 960Gb to
the 1.1Tb with the addition of the eighth drive. This is on a FC2 based
install, Duron 833, 256 meg.
Richard
ReiserFS: md0: found reiserfs format "3.6" with standard journal
ReiserFS: md0: using ordered data mode
ReiserFS: md0: journal params: device md0, size 8192, journal first
block 18, max trans len 1024, max batch 900, max commit age 30, max
trans age 30
ReiserFS: md0: checking transaction log (md0)
ReiserFS: md0: replayed 3 transactions in 18 seconds
ReiserFS: md0: Using r5 hash to sort names
ReiserFS: md0: Removing [2 1282214 0x0 SD]..<0>REISERFS: panic (device
md0): journal-1413: journal_mark_dirty: j_len (1024) is too big
------------[ cut here ]------------
kernel BUG at fs/reiserfs/prints.c:362!
invalid operand: 0000 [#1]
Modules linked in: raid5 xor iteraid sd_mod autofs4 r8169 sg scsi_mod
dm_mod uhci_hcd button battery asus_acpi ac ext3 jbd
CPU: 0
EIP: 0060:[<c019416a>] Not tainted
EFLAGS: 00010292 (2.6.8-1.521custom)
EIP is at reiserfs_panic+0x4a/0x70
eax: 0000005c ebx: c03422a8 ecx: c0380f78 edx: c0380f78
esi: c13b1e00 edi: c13b1f2c ebp: c13b1e00 esp: cc852950
ds: 007b es: 007b ss: 0068
Process mount (pid: 1204, threadinfo=cc852000 task=cccb2310)
Stack: c0347a48 c13b1f2c c0419c60 cc852d1c ffffffff ca5a59a0 c01a28f8
c13b1e00
c03498dc 00000400 c13b1e00 c019e589 000017bc d08f50e4 00007fff
c13b1e00
00000000 00007fff c13b1e00 000017bc 0bde7fff c017e384 cc852a20
c95ee018
Call Trace:
[<c01a28f8>] journal_mark_dirty+0x288/0x2a0
[<c019e589>] get_bitmap_node+0x39/0xa0
[<c017e384>] _reiserfs_free_block+0xf4/0x180
[<c019ac35>] prepare_for_delete_or_cut+0x515/0x710
[<c0190d61>] unfix_nodes+0x61/0x140
[<c019bbbc>] reiserfs_cut_from_item+0xac/0x4f0
[<c019c2fc>] reiserfs_do_truncate+0x26c/0x520
[<c019b6bb>] reiserfs_delete_object+0x2b/0x60
[<c0185777>] reiserfs_delete_inode+0xb7/0x100
[<c011a587>] printk+0xf7/0x140
[<c01856c0>] reiserfs_delete_inode+0x0/0x100
[<c015eb04>] generic_delete_inode+0x74/0xf0
[<c015ecdc>] iput+0x4c/0x60
[<c01912f5>] finish_unfinished+0x1c5/0x310
[<c0154e09>] __lookup_hash+0x89/0xb0
[<c01a29a6>] journal_end+0x96/0xc0
[<c01931ba>] reiserfs_fill_super+0x4da/0x640
[<c0187ef0>] reiserfs_init_locked_inode+0x0/0x10
[<c020e40f>] snprintf+0x1f/0x30
[<c014e67f>] get_sb_bdev+0xef/0x120
[<c019339b>] get_super_block+0x1b/0x40
[<c0192ce0>] reiserfs_fill_super+0x0/0x640
[<c014e871>] do_kern_mount+0x51/0xe0
[<c016127a>] do_new_mount+0x8a/0xc0
[<c016182f>] do_mount+0x13f/0x180
[<c020f50a>] __copy_from_user_ll+0x3a/0x70
[<c016167c>] copy_mount_options+0x6c/0xe0
[<c0161b9e>] sys_mount+0x8e/0xf0
[<c032ce0f>] syscall_call+0x7/0xb
Code: 0f 0b 6a 01 ce 27 34 c0 85 f6 c7 44 24 08 60 9c 41 c0 c7 04
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: Oops with large file in 2.6.8, reiser 3.6.13 2004-10-19 12:28 Oops with large file in 2.6.8, reiser 3.6.13 Richard Gregory @ 2004-10-24 8:37 ` Alex Zarochentsev [not found] ` <41821398.3050900@liv.ac.uk> 0 siblings, 1 reply; 6+ messages in thread From: Alex Zarochentsev @ 2004-10-24 8:37 UTC (permalink / raw) To: Richard Gregory; +Cc: reiserfs-list Hello, please try the following patch (it is for 2.6.6, but i expect it to work with 2.6.8): ========================================= --- linux-2.6.6/fs/reiserfs/stree.c.orig 2004-10-23 16:43:11.412335592 +0400 +++ linux-2.6.6/fs/reiserfs/stree.c 2004-10-23 17:09:36.983292168 +0400 @@ -1721,8 +1721,14 @@ void reiserfs_do_truncate (struct reiser set_cpu_key_k_offset (&s_item_key, n_file_size); do { + loff_t to_size; + + to_size = n_file_size - (p_s_inode->i_sb->s_blocksize * 2); + if (to_size < n_new_file_size) + to_size = n_new_file_size; + /* Cut or delete file item. */ - n_deleted = reiserfs_cut_from_item(th, &s_search_path, &s_item_key, p_s_inode, page, n_new_file_size); + n_deleted = reiserfs_cut_from_item(th, &s_search_path, &s_item_key, p_s_inode, page, to_size); if (n_deleted < 0) { reiserfs_warning ("vs-5665: reiserfs_do_truncate: reiserfs_cut_from_item failed"); reiserfs_check_path(&s_search_path) ; @@ -1731,7 +1737,7 @@ void reiserfs_do_truncate (struct reiser RFALSE( n_deleted > n_file_size, "PAP-5670: reiserfs_cut_from_item: too many bytes deleted: deleted %d, file_size %lu, item_key %K", - n_deleted, n_file_size, &s_item_key); + n_deleted, to_size, &s_item_key); /* Change key to search the last file item. */ n_file_size -= n_deleted; @@ -1747,7 +1753,7 @@ void reiserfs_do_truncate (struct reiser ** sure the file is consistent before ending the current trans ** and starting a new one */ - if (journal_transaction_should_end(th, th->t_blocks_allocated)) { + if (1 || journal_transaction_should_end(th, th->t_blocks_allocated)) { int orig_len_alloc = th->t_blocks_allocated ; decrement_counters_in_path(&s_search_path) ; ========================================= On Tue, Oct 19, 2004 at 01:28:20PM +0100, Richard Gregory wrote: > Have managed to create an Oops in the reiser code, dmesg output below. > This was on a software raid5 setup, with 8 160Gb disks, creating around > 1.1Tb of storage. There was around 400Gb of content on this filesystem, > then as an over night test, /dev/zero was dd'ed to a file on the > filesystem, creating an approx 720Gb file and filling the filesystem. > > The problem came when I tried to delete it, rm'ing it caused an Oops in > the reiser code. The system was rebooted, but mounting the filesystem > gave the oops below. > > Am currently running reiserfsck --check to see if this file can be > removed some other way, otherwise, it will mean a very long reformat and > copy operation. > > Something else, this filesystem had recently been resized from 960Gb to > the 1.1Tb with the addition of the eighth drive. This is on a FC2 based > install, Duron 833, 256 meg. > > > Richard > > > ReiserFS: md0: found reiserfs format "3.6" with standard journal > ReiserFS: md0: using ordered data mode > ReiserFS: md0: journal params: device md0, size 8192, journal first > block 18, max trans len 1024, max batch 900, max commit age 30, max > trans age 30 > ReiserFS: md0: checking transaction log (md0) > ReiserFS: md0: replayed 3 transactions in 18 seconds > ReiserFS: md0: Using r5 hash to sort names > ReiserFS: md0: Removing [2 1282214 0x0 SD]..<0>REISERFS: panic (device > md0): journal-1413: journal_mark_dirty: j_len (1024) is too big > > ------------[ cut here ]------------ > kernel BUG at fs/reiserfs/prints.c:362! > invalid operand: 0000 [#1] > Modules linked in: raid5 xor iteraid sd_mod autofs4 r8169 sg scsi_mod > dm_mod uhci_hcd button battery asus_acpi ac ext3 jbd > CPU: 0 > EIP: 0060:[<c019416a>] Not tainted > EFLAGS: 00010292 (2.6.8-1.521custom) > EIP is at reiserfs_panic+0x4a/0x70 > eax: 0000005c ebx: c03422a8 ecx: c0380f78 edx: c0380f78 > esi: c13b1e00 edi: c13b1f2c ebp: c13b1e00 esp: cc852950 > ds: 007b es: 007b ss: 0068 > > Process mount (pid: 1204, threadinfo=cc852000 task=cccb2310) > Stack: c0347a48 c13b1f2c c0419c60 cc852d1c ffffffff ca5a59a0 c01a28f8 > c13b1e00 > c03498dc 00000400 c13b1e00 c019e589 000017bc d08f50e4 00007fff > c13b1e00 > 00000000 00007fff c13b1e00 000017bc 0bde7fff c017e384 cc852a20 > c95ee018 > Call Trace: > [<c01a28f8>] journal_mark_dirty+0x288/0x2a0 > [<c019e589>] get_bitmap_node+0x39/0xa0 > [<c017e384>] _reiserfs_free_block+0xf4/0x180 > [<c019ac35>] prepare_for_delete_or_cut+0x515/0x710 > [<c0190d61>] unfix_nodes+0x61/0x140 > [<c019bbbc>] reiserfs_cut_from_item+0xac/0x4f0 > [<c019c2fc>] reiserfs_do_truncate+0x26c/0x520 > [<c019b6bb>] reiserfs_delete_object+0x2b/0x60 > [<c0185777>] reiserfs_delete_inode+0xb7/0x100 > [<c011a587>] printk+0xf7/0x140 > [<c01856c0>] reiserfs_delete_inode+0x0/0x100 > [<c015eb04>] generic_delete_inode+0x74/0xf0 > [<c015ecdc>] iput+0x4c/0x60 > [<c01912f5>] finish_unfinished+0x1c5/0x310 > [<c0154e09>] __lookup_hash+0x89/0xb0 > [<c01a29a6>] journal_end+0x96/0xc0 > [<c01931ba>] reiserfs_fill_super+0x4da/0x640 > [<c0187ef0>] reiserfs_init_locked_inode+0x0/0x10 > [<c020e40f>] snprintf+0x1f/0x30 > [<c014e67f>] get_sb_bdev+0xef/0x120 > [<c019339b>] get_super_block+0x1b/0x40 > [<c0192ce0>] reiserfs_fill_super+0x0/0x640 > [<c014e871>] do_kern_mount+0x51/0xe0 > [<c016127a>] do_new_mount+0x8a/0xc0 > [<c016182f>] do_mount+0x13f/0x180 > [<c020f50a>] __copy_from_user_ll+0x3a/0x70 > [<c016167c>] copy_mount_options+0x6c/0xe0 > [<c0161b9e>] sys_mount+0x8e/0xf0 > [<c032ce0f>] syscall_call+0x7/0xb > Code: 0f 0b 6a 01 ce 27 34 c0 85 f6 c7 44 24 08 60 9c 41 c0 c7 04 -- Alex. ^ permalink raw reply [flat|nested] 6+ messages in thread
[parent not found: <41821398.3050900@liv.ac.uk>]
* Re: Oops with large file in 2.6.8, reiser 3.6.13 [not found] ` <41821398.3050900@liv.ac.uk> @ 2004-10-29 10:46 ` Alex Zarochentsev 2004-11-29 19:46 ` Jeff Mahoney 0 siblings, 1 reply; 6+ messages in thread From: Alex Zarochentsev @ 2004-10-29 10:46 UTC (permalink / raw) To: Richard Gregory; +Cc: reiserfs-list Hello, On Fri, Oct 29, 2004 at 10:55:36AM +0100, Richard Gregory wrote: > Hi Alex, > > That fixed it. I created a 617gig file that filled the filesystem. It > then deleted without a problem. The delete took a long time, but at > least it got there. Thanks a lot. Your reply is what we needed to make a correct fix. > Thanks, > > Richard > > Alex Zarochentsev wrote: > >Hello, > > > >please try the following patch (it is for 2.6.6, > >but i expect it to work with 2.6.8): > >========================================= > >--- linux-2.6.6/fs/reiserfs/stree.c.orig 2004-10-23 > >16:43:11.412335592 +0400 > >+++ linux-2.6.6/fs/reiserfs/stree.c 2004-10-23 17:09:36.983292168 +0400 > >@@ -1721,8 +1721,14 @@ void reiserfs_do_truncate (struct reiser > > set_cpu_key_k_offset (&s_item_key, n_file_size); > > > > do { > >+ loff_t to_size; > >+ > >+ to_size = n_file_size - (p_s_inode->i_sb->s_blocksize * 2); > >+ if (to_size < n_new_file_size) > >+ to_size = n_new_file_size; > >+ > > /* Cut or delete file item. */ > >- n_deleted = reiserfs_cut_from_item(th, &s_search_path, &s_item_key, > >p_s_inode, page, n_new_file_size); > >+ n_deleted = reiserfs_cut_from_item(th, &s_search_path, &s_item_key, > >p_s_inode, page, to_size); > > if (n_deleted < 0) { > > reiserfs_warning ("vs-5665: reiserfs_do_truncate: > > reiserfs_cut_from_item failed"); > > reiserfs_check_path(&s_search_path) ; > >@@ -1731,7 +1737,7 @@ void reiserfs_do_truncate (struct reiser > > > > RFALSE( n_deleted > n_file_size, > > "PAP-5670: reiserfs_cut_from_item: too many bytes deleted: > > deleted %d, file_size %lu, item_key %K", > >- n_deleted, n_file_size, &s_item_key); > >+ n_deleted, to_size, &s_item_key); > > > > /* Change key to search the last file item. */ > > n_file_size -= n_deleted; > >@@ -1747,7 +1753,7 @@ void reiserfs_do_truncate (struct reiser > > ** sure the file is consistent before ending the current trans > > ** and starting a new one > > */ > >- if (journal_transaction_should_end(th, th->t_blocks_allocated)) { > >+ if (1 || journal_transaction_should_end(th, > >th->t_blocks_allocated)) { > > int orig_len_alloc = th->t_blocks_allocated ; > > decrement_counters_in_path(&s_search_path) ; > > > >========================================= > >On Tue, Oct 19, 2004 at 01:28:20PM +0100, Richard Gregory wrote: > > > >>Have managed to create an Oops in the reiser code, dmesg output below. > >>This was on a software raid5 setup, with 8 160Gb disks, creating around > >>1.1Tb of storage. There was around 400Gb of content on this filesystem, > >>then as an over night test, /dev/zero was dd'ed to a file on the > >>filesystem, creating an approx 720Gb file and filling the filesystem. > >> > >>The problem came when I tried to delete it, rm'ing it caused an Oops in > >>the reiser code. The system was rebooted, but mounting the filesystem > >>gave the oops below. > >> > >>Am currently running reiserfsck --check to see if this file can be > >>removed some other way, otherwise, it will mean a very long reformat and > >>copy operation. > >> > >>Something else, this filesystem had recently been resized from 960Gb to > >>the 1.1Tb with the addition of the eighth drive. This is on a FC2 based > >>install, Duron 833, 256 meg. > >> > >> > >>Richard > >> > >> > >>ReiserFS: md0: found reiserfs format "3.6" with standard journal > >>ReiserFS: md0: using ordered data mode > >>ReiserFS: md0: journal params: device md0, size 8192, journal first > >>block 18, max trans len 1024, max batch 900, max commit age 30, max > >>trans age 30 > >>ReiserFS: md0: checking transaction log (md0) > >>ReiserFS: md0: replayed 3 transactions in 18 seconds > >>ReiserFS: md0: Using r5 hash to sort names > >>ReiserFS: md0: Removing [2 1282214 0x0 SD]..<0>REISERFS: panic (device > >>md0): journal-1413: journal_mark_dirty: j_len (1024) is too big > >> > >>------------[ cut here ]------------ > >>kernel BUG at fs/reiserfs/prints.c:362! > >>invalid operand: 0000 [#1] > >>Modules linked in: raid5 xor iteraid sd_mod autofs4 r8169 sg scsi_mod > >>dm_mod uhci_hcd button battery asus_acpi ac ext3 jbd > >>CPU: 0 > >>EIP: 0060:[<c019416a>] Not tainted > >>EFLAGS: 00010292 (2.6.8-1.521custom) > >>EIP is at reiserfs_panic+0x4a/0x70 > >>eax: 0000005c ebx: c03422a8 ecx: c0380f78 edx: c0380f78 > >>esi: c13b1e00 edi: c13b1f2c ebp: c13b1e00 esp: cc852950 > >>ds: 007b es: 007b ss: 0068 > >> > >>Process mount (pid: 1204, threadinfo=cc852000 task=cccb2310) > >>Stack: c0347a48 c13b1f2c c0419c60 cc852d1c ffffffff ca5a59a0 c01a28f8 > >>c13b1e00 > >> c03498dc 00000400 c13b1e00 c019e589 000017bc d08f50e4 00007fff > >>c13b1e00 > >> 00000000 00007fff c13b1e00 000017bc 0bde7fff c017e384 cc852a20 > >>c95ee018 > >>Call Trace: > >>[<c01a28f8>] journal_mark_dirty+0x288/0x2a0 > >>[<c019e589>] get_bitmap_node+0x39/0xa0 > >>[<c017e384>] _reiserfs_free_block+0xf4/0x180 > >>[<c019ac35>] prepare_for_delete_or_cut+0x515/0x710 > >>[<c0190d61>] unfix_nodes+0x61/0x140 > >>[<c019bbbc>] reiserfs_cut_from_item+0xac/0x4f0 > >>[<c019c2fc>] reiserfs_do_truncate+0x26c/0x520 > >>[<c019b6bb>] reiserfs_delete_object+0x2b/0x60 > >>[<c0185777>] reiserfs_delete_inode+0xb7/0x100 > >>[<c011a587>] printk+0xf7/0x140 > >>[<c01856c0>] reiserfs_delete_inode+0x0/0x100 > >>[<c015eb04>] generic_delete_inode+0x74/0xf0 > >>[<c015ecdc>] iput+0x4c/0x60 > >>[<c01912f5>] finish_unfinished+0x1c5/0x310 > >>[<c0154e09>] __lookup_hash+0x89/0xb0 > >>[<c01a29a6>] journal_end+0x96/0xc0 > >>[<c01931ba>] reiserfs_fill_super+0x4da/0x640 > >>[<c0187ef0>] reiserfs_init_locked_inode+0x0/0x10 > >>[<c020e40f>] snprintf+0x1f/0x30 > >>[<c014e67f>] get_sb_bdev+0xef/0x120 > >>[<c019339b>] get_super_block+0x1b/0x40 > >>[<c0192ce0>] reiserfs_fill_super+0x0/0x640 > >>[<c014e871>] do_kern_mount+0x51/0xe0 > >>[<c016127a>] do_new_mount+0x8a/0xc0 > >>[<c016182f>] do_mount+0x13f/0x180 > >>[<c020f50a>] __copy_from_user_ll+0x3a/0x70 > >>[<c016167c>] copy_mount_options+0x6c/0xe0 > >>[<c0161b9e>] sys_mount+0x8e/0xf0 > >>[<c032ce0f>] syscall_call+0x7/0xb > >>Code: 0f 0b 6a 01 ce 27 34 c0 85 f6 c7 44 24 08 60 9c 41 c0 c7 04 > > > > -- Alex. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Oops with large file in 2.6.8, reiser 3.6.13 2004-10-29 10:46 ` Alex Zarochentsev @ 2004-11-29 19:46 ` Jeff Mahoney 2004-11-29 21:00 ` Chris Mason 0 siblings, 1 reply; 6+ messages in thread From: Jeff Mahoney @ 2004-11-29 19:46 UTC (permalink / raw) To: Alex Zarochentsev; +Cc: Richard Gregory, reiserfs-list -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Alex Zarochentsev wrote: | Hello, | | On Fri, Oct 29, 2004 at 10:55:36AM +0100, Richard Gregory wrote: | |>Hi Alex, |> |>That fixed it. I created a 617gig file that filled the filesystem. It |>then deleted without a problem. The delete took a long time, but at |>least it got there. | | | Thanks a lot. Your reply is what we needed to make a correct fix. Alex - Is the fix in the parent message the "correct" fix? It seems to leave an if (1 || ...) in, and I've yet to see the fix appear in bk or lkml. Thanks. - -Jeff - -- Jeff Mahoney SuSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBq3yCLPWxlyuTD7IRAsuxAJ9ruBsMyRhPpNAv8oKdCuGxrhYYYQCfQFYw Ja1Li6nPFrOzpbj/W7aLXls= =rfuo -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Oops with large file in 2.6.8, reiser 3.6.13 2004-11-29 19:46 ` Jeff Mahoney @ 2004-11-29 21:00 ` Chris Mason 2004-11-29 21:17 ` Jeff Mahoney 0 siblings, 1 reply; 6+ messages in thread From: Chris Mason @ 2004-11-29 21:00 UTC (permalink / raw) To: Jeff Mahoney; +Cc: Alex Zarochentsev, Richard Gregory, reiserfs-list On Mon, 2004-11-29 at 14:46 -0500, Jeff Mahoney wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Alex Zarochentsev wrote: > | Hello, > | > | On Fri, Oct 29, 2004 at 10:55:36AM +0100, Richard Gregory wrote: > | > |>Hi Alex, > |> > |>That fixed it. I created a 617gig file that filled the filesystem. It > |>then deleted without a problem. The delete took a long time, but at > |>least it got there. > | > | > | Thanks a lot. Your reply is what we needed to make a correct fix. > > Alex - > > Is the fix in the parent message the "correct" fix? It seems to leave an > if (1 || ...) in, and I've yet to see the fix appear in bk or lkml. Jeff, look for subject: reiserfs_do_truncate patch from zam. -chris ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Oops with large file in 2.6.8, reiser 3.6.13 2004-11-29 21:00 ` Chris Mason @ 2004-11-29 21:17 ` Jeff Mahoney 0 siblings, 0 replies; 6+ messages in thread From: Jeff Mahoney @ 2004-11-29 21:17 UTC (permalink / raw) To: Chris Mason; +Cc: Alex Zarochentsev, Richard Gregory, reiserfs-list -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Chris Mason wrote: | On Mon, 2004-11-29 at 14:46 -0500, Jeff Mahoney wrote: | |>-----BEGIN PGP SIGNED MESSAGE----- |>Hash: SHA1 |> |>Alex Zarochentsev wrote: |>| Hello, |>| |>| On Fri, Oct 29, 2004 at 10:55:36AM +0100, Richard Gregory wrote: |>| |>|>Hi Alex, |>|> |>|>That fixed it. I created a 617gig file that filled the filesystem. It |>|>then deleted without a problem. The delete took a long time, but at |>|>least it got there. |>| |>| |>| Thanks a lot. Your reply is what we needed to make a correct fix. |> |>Alex - |> |>Is the fix in the parent message the "correct" fix? It seems to leave an |>if (1 || ...) in, and I've yet to see the fix appear in bk or lkml. | | | Jeff, look for subject: reiserfs_do_truncate patch from zam. | | -chris | | | Hey, look at that. I was reviewing unread messages in reiserfs-list, and happened apon this one. I didn't make the correlation and it didn't get posted to lkml, so I missed it. Thanks. - -Jeff - -- Jeff Mahoney SuSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBq5HuLPWxlyuTD7IRAtVGAJ40jniOqYgGc0QlnffTnqV7Cqi09wCdG3WE Y/03TqtrQM9XHteHtQQnlOc= =Zcxh -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2004-11-29 21:17 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-10-19 12:28 Oops with large file in 2.6.8, reiser 3.6.13 Richard Gregory
2004-10-24 8:37 ` Alex Zarochentsev
[not found] ` <41821398.3050900@liv.ac.uk>
2004-10-29 10:46 ` Alex Zarochentsev
2004-11-29 19:46 ` Jeff Mahoney
2004-11-29 21:00 ` Chris Mason
2004-11-29 21:17 ` Jeff Mahoney
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.