* XFS recovery resumes... [not found] <29874428.3384.1376259762936.JavaMail.root@benjamin.baylink.com> @ 2013-08-11 22:36 ` Jay Ashworth 2013-08-18 21:38 ` Jay Ashworth 2013-08-22 9:16 ` XFS recovery resumes Stefan Ring 0 siblings, 2 replies; 23+ messages in thread From: Jay Ashworth @ 2013-08-11 22:36 UTC (permalink / raw) To: xfs I'm trying to dedupe the two large XFS filesystems on which I have DVR recordings, so that I can walk around amongst the available HDDs and create new filesystems under everything. Every time I rm a file, the filesystem blows up, and the driver shuts it down. Some background: At the moment, I have 2 devices, /dev/sdd1 mounted on /appl/media4, and /dev/sda1 mounted on /appl/media5, and a large script, created by hand- hacking the output of a perl dupe finder script. The large script was mangled so that it would remove anything that was a dupe from media4, unless the file was an unlabeled lost+found on media5, and had a name on media4. In that case, I removed the file on media5, and then moved it from media4 to media5. After the hand-hacking on the script, I sorted it to do all the rm's first, and then all the mv's, to make sure free space when up before it went down. And, of course, when I ran the script, it caused the XFS driver to cough and die, leading to error 5s and gnashing of teeth. I unmounted media5, remounted it (which worked), and unmounted it again to run xfs_repair -n. That found one inode that was pointing somewhere bogus (and I apologize that I can't copy that in; I was running under screen, and it doesn't cooperate with scrollback well). I ran an xfs_repair without -n, and it found and fixed the one error without complaint. I mounted and unmounted it successfully (nothing notable in dmesg), and reran xfs_repair -n, which, this time, ran without any problems reported. So I remounted the filesystem, and again tried to run the script. And again, it tripped something, and the filesystem unmounted, and here's the dmesg output from the first and second trips: First time: [169324.654803] XFS (sdd1): Ending clean mount [1278872.471310] ccbc0000: 41 42 54 42 00 00 00 04 df ff ff ff ff ff ff ff ABTB............ [1278872.471324] XFS (sda1): Internal error xfs_btree_check_sblock at line 119 of file /home/abuild/rpmbuild/BUI LD/kernel-default-3.4.47/linux-3.4/fs/xfs/xfs_btree.c. Caller 0xe3caf3a5 [1278872.471328] [1278872.471334] Pid: 16696, comm: rm Not tainted 3.4.47-2.38-default #1 [1278872.471338] Call Trace: [1278872.471368] [<c0205349>] try_stack_unwind+0x199/0x1b0 [1278872.471382] [<c02041c7>] dump_trace+0x47/0xf0 [1278872.471391] [<c02053ab>] show_trace_log_lvl+0x4b/0x60 [1278872.471398] [<c02053d8>] show_trace+0x18/0x20 [1278872.471409] [<c06825ba>] dump_stack+0x6d/0x72 [1278872.471534] [<e3c826ed>] xfs_corruption_error+0x5d/0x90 [xfs] [1278872.471650] [<e3cae9f4>] xfs_btree_check_sblock+0x74/0x100 [xfs] [1278872.471834] [<e3caf3a5>] xfs_btree_read_buf_block.constprop.24+0x95/0xb0 [xfs] [1278872.472007] [<e3caf423>] xfs_btree_lookup_get_block+0x63/0xc0 [xfs] [1278872.472207] [<e3cb251a>] xfs_btree_lookup+0x9a/0x460 [xfs] [1278872.472379] [<e3c9576a>] xfs_alloc_fixup_trees+0x27a/0x370 [xfs] [1278872.472510] [<e3c97b63>] xfs_alloc_ag_vextent_size+0x523/0x670 [xfs] [1278872.472647] [<e3c9874f>] xfs_alloc_ag_vextent+0x9f/0x100 [xfs] [1278872.472781] [<e3c9899a>] xfs_alloc_fix_freelist+0x1ea/0x450 [xfs] [1278872.472915] [<e3c98cd5>] xfs_free_extent+0xd5/0x160 [xfs] [1278872.473052] [<e3ca9f4e>] xfs_bmap_finish+0x15e/0x1b0 [xfs] [1278872.473214] [<e3cc47e9>] xfs_itruncate_extents+0x159/0x2f0 [xfs] [1278872.473422] [<e3c92ff5>] xfs_inactive+0x335/0x4a0 [xfs] [1278872.473516] [<c0337e84>] evict+0x84/0x150 [1278872.473530] [<c032ea22>] do_unlinkat+0x102/0x160 [1278872.473546] [<c069331c>] sysenter_do_call+0x12/0x28 [1278872.473578] [<b779b430>] 0xb779b42f [1278872.473583] XFS (sda1): Corruption detected. Unmount and run xfs_repair [1278872.473599] XFS (sda1): xfs_do_force_shutdown(0x8) called from line 3732 of file /home/abuild/rpmbuild/BUIL D/kernel-default-3.4.47/linux-3.4/fs/xfs/xfs_bmap.c. Return address = 0xe3ca9f8c [1278872.584543] XFS (sda1): Corruption of in-memory data detected. Shutting down filesystem [1278872.584555] XFS (sda1): Please umount the filesystem and rectify the problem(s) [1278881.888038] XFS (sda1): xfs_log_force: error 5 returned. [1278911.968046] XFS (sda1): xfs_log_force: error 5 returned. [1278942.048037] XFS (sda1): xfs_log_force: error 5 returned. [1278972.128049] XFS (sda1): xfs_log_force: error 5 returned. [1279002.208042] XFS (sda1): xfs_log_force: error 5 returned. [1279028.046331] XFS (sda1): xfs_log_force: error 5 returned. [1279028.046349] XFS (sda1): xfs_do_force_shutdown(0x1) called from line 1031 of file /home/abuild/rpmbuild/BUIL D/kernel-default-3.4.47/linux-3.4/fs/xfs/xfs_buf.c. Return address = 0xe3c813c0 [1279028.060676] XFS (sda1): xfs_log_force: error 5 returned. [1279028.067532] XFS (sda1): xfs_log_force: error 5 returned. Here's me mounting and umounting, with the xfs_repair runs in the middle: [1279032.147391] XFS (sda1): Mounting Filesystem [1279032.305924] XFS (sda1): Starting recovery (logdev: internal) [1279035.263630] XFS (sda1): Ending recovery (logdev: internal) [1279238.566041] XFS (sda1): Mounting Filesystem [1279238.713051] XFS (sda1): Ending clean mount [1279286.829764] XFS (sda1): Mounting Filesystem [1279286.982409] XFS (sda1): Ending clean mount [1279368.607644] XFS (sda1): Mounting Filesystem [1279368.755048] XFS (sda1): Ending clean mount Second time: [1279388.664986] c1516000: 41 42 54 43 00 00 00 04 df ff ff ff ff ff ff ff ABTC............ [1279388.665000] XFS (sda1): Internal error xfs_btree_check_sblock at line 119 of file /home/abuild/rpmbuild/BUI LD/kernel-default-3.4.47/linux-3.4/fs/xfs/xfs_btree.c. Caller 0xe3caf3a5 [1279388.665004] [1279388.665010] Pid: 18452, comm: rm Not tainted 3.4.47-2.38-default #1 [1279388.665015] Call Trace: [1279388.665045] [<c0205349>] try_stack_unwind+0x199/0x1b0 [1279388.665058] [<c02041c7>] dump_trace+0x47/0xf0 [1279388.665067] [<c02053ab>] show_trace_log_lvl+0x4b/0x60 [1279388.665075] [<c02053d8>] show_trace+0x18/0x20 [1279388.665086] [<c06825ba>] dump_stack+0x6d/0x72 [1279388.665211] [<e3c826ed>] xfs_corruption_error+0x5d/0x90 [xfs] [1279388.665327] [<e3cae9f4>] xfs_btree_check_sblock+0x74/0x100 [xfs] [1279388.665511] [<e3caf3a5>] xfs_btree_read_buf_block.constprop.24+0x95/0xb0 [xfs] [1279388.665684] [<e3caf423>] xfs_btree_lookup_get_block+0x63/0xc0 [xfs] [1279388.665856] [<e3cb251a>] xfs_btree_lookup+0x9a/0x460 [xfs] [1279388.666029] [<e3c97691>] xfs_alloc_ag_vextent_size+0x51/0x670 [xfs] [1279388.666163] [<e3c9874f>] xfs_alloc_ag_vextent+0x9f/0x100 [xfs] [1279388.666298] [<e3c9899a>] xfs_alloc_fix_freelist+0x1ea/0x450 [xfs] [1279388.666433] [<e3c98cd5>] xfs_free_extent+0xd5/0x160 [xfs] [1279388.666571] [<e3ca9f4e>] xfs_bmap_finish+0x15e/0x1b0 [xfs] [1279388.666734] [<e3cc47e9>] xfs_itruncate_extents+0x159/0x2f0 [xfs] [1279388.666944] [<e3c92ff5>] xfs_inactive+0x335/0x4a0 [xfs] [1279388.667039] [<c0337e84>] evict+0x84/0x150 [1279388.667053] [<c032ea22>] do_unlinkat+0x102/0x160 [1279388.667069] [<c069331c>] sysenter_do_call+0x12/0x28 [1279388.667100] [<b772f430>] 0xb772f42f [1279388.667105] XFS (sda1): Corruption detected. Unmount and run xfs_repair [1279388.667120] XFS (sda1): xfs_do_force_shutdown(0x8) called from line 3732 of file /home/abuild/rpmbuild/BUIL D/kernel-default-3.4.47/linux-3.4/fs/xfs/xfs_bmap.c. Return address = 0xe3ca9f8c [1279388.690497] XFS (sda1): Corruption of in-memory data detected. Shutting down filesystem [1279388.690506] XFS (sda1): Please umount the filesystem and rectify the problem(s) [1279398.816060] XFS (sda1): xfs_log_force: error 5 returned. [1279428.832065] XFS (sda1): xfs_log_force: error 5 returned. [ ... ] It's not entirely clear to me whether this problem is specific inodes that are corrupt or not, or just something in the filesystem header. Kernel: Linux duckling 3.4.47-2.38-default #1 SMP Fri May 31 20:17:40 UTC 2013 (3961086) i686 athlon i386 GNU/Linux progs: xfsprogs-3.1.6-9.1.2.i586 Worst case, if I can't get these to behave, I'll just beg, borrow or steal a spare 3T and copy everything to it, and then redo the FSs on these 2 drives, but it would a bit easier if I could get them to settle down a bit... Anyone have any suggestions as to which mole I should whack next? Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 23+ messages in thread
* XFS recovery resumes... 2013-08-11 22:36 ` XFS recovery resumes Jay Ashworth @ 2013-08-18 21:38 ` Jay Ashworth 2013-08-18 21:51 ` Joe Landman 2013-08-18 22:06 ` Stan Hoeppner 2013-08-22 9:16 ` XFS recovery resumes Stefan Ring 1 sibling, 2 replies; 23+ messages in thread From: Jay Ashworth @ 2013-08-18 21:38 UTC (permalink / raw) To: xfs I'm trying to dedupe the two large XFS filesystems on which I have DVR recordings, so that I can walk around amongst the available HDDs and create new filesystems under everything. Every time I rm a file, the filesystem blows up, and the driver shuts it down. Some background: At the moment, I have 2 devices, /dev/sdd1 mounted on /appl/media4, and /dev/sda1 mounted on /appl/media5, and a large script, created by hand- hacking the output of a perl dupe finder script. The large script was mangled so that it would remove anything that was a dupe from media4, unless the file was an unlabeled lost+found on media5, and had a name on media4. In that case, I removed the file on media5, and then moved it from media4 to media5. After the hand-hacking on the script, I sorted it to do all the rm's first, and then all the mv's, to make sure free space when up before it went down. And, of course, when I ran the script, it caused the XFS driver to cough and die, leading to error 5s and gnashing of teeth. I unmounted media5, remounted it (which worked), and unmounted it again to run xfs_repair -n. That found one inode that was pointing somewhere bogus (and I apologize that I can't copy that in; I was running under screen, and it doesn't cooperate with scrollback well). I ran an xfs_repair without -n, and it found and fixed the one error without complaint. I mounted and unmounted it successfully (nothing notable in dmesg), and reran xfs_repair -n, which, this time, ran without any problems reported. So I remounted the filesystem, and again tried to run the script. And again, it tripped something, and the filesystem unmounted, and here's the dmesg output from the first and second trips: First time: [169324.654803] XFS (sdd1): Ending clean mount [1278872.471310] ccbc0000: 41 42 54 42 00 00 00 04 df ff ff ff ff ff ff ff ABTB............ [1278872.471324] XFS (sda1): Internal error xfs_btree_check_sblock at line 119 of file /home/abuild/rpmbuild/BUI LD/kernel-default-3.4.47/linux-3.4/fs/xfs/xfs_btree.c. Caller 0xe3caf3a5 [1278872.471328] [1278872.471334] Pid: 16696, comm: rm Not tainted 3.4.47-2.38-default #1 [1278872.471338] Call Trace: [1278872.471368] [<c0205349>] try_stack_unwind+0x199/0x1b0 [1278872.471382] [<c02041c7>] dump_trace+0x47/0xf0 [1278872.471391] [<c02053ab>] show_trace_log_lvl+0x4b/0x60 [1278872.471398] [<c02053d8>] show_trace+0x18/0x20 [1278872.471409] [<c06825ba>] dump_stack+0x6d/0x72 [1278872.471534] [<e3c826ed>] xfs_corruption_error+0x5d/0x90 [xfs] [1278872.471650] [<e3cae9f4>] xfs_btree_check_sblock+0x74/0x100 [xfs] [1278872.471834] [<e3caf3a5>] xfs_btree_read_buf_block.constprop.24+0x95/0xb0 [xfs] [1278872.472007] [<e3caf423>] xfs_btree_lookup_get_block+0x63/0xc0 [xfs] [1278872.472207] [<e3cb251a>] xfs_btree_lookup+0x9a/0x460 [xfs] [1278872.472379] [<e3c9576a>] xfs_alloc_fixup_trees+0x27a/0x370 [xfs] [1278872.472510] [<e3c97b63>] xfs_alloc_ag_vextent_size+0x523/0x670 [xfs] [1278872.472647] [<e3c9874f>] xfs_alloc_ag_vextent+0x9f/0x100 [xfs] [1278872.472781] [<e3c9899a>] xfs_alloc_fix_freelist+0x1ea/0x450 [xfs] [1278872.472915] [<e3c98cd5>] xfs_free_extent+0xd5/0x160 [xfs] [1278872.473052] [<e3ca9f4e>] xfs_bmap_finish+0x15e/0x1b0 [xfs] [1278872.473214] [<e3cc47e9>] xfs_itruncate_extents+0x159/0x2f0 [xfs] [1278872.473422] [<e3c92ff5>] xfs_inactive+0x335/0x4a0 [xfs] [1278872.473516] [<c0337e84>] evict+0x84/0x150 [1278872.473530] [<c032ea22>] do_unlinkat+0x102/0x160 [1278872.473546] [<c069331c>] sysenter_do_call+0x12/0x28 [1278872.473578] [<b779b430>] 0xb779b42f [1278872.473583] XFS (sda1): Corruption detected. Unmount and run xfs_repair [1278872.473599] XFS (sda1): xfs_do_force_shutdown(0x8) called from line 3732 of file /home/abuild/rpmbuild/BUIL D/kernel-default-3.4.47/linux-3.4/fs/xfs/xfs_bmap.c. Return address = 0xe3ca9f8c [1278872.584543] XFS (sda1): Corruption of in-memory data detected. Shutting down filesystem [1278872.584555] XFS (sda1): Please umount the filesystem and rectify the problem(s) [1278881.888038] XFS (sda1): xfs_log_force: error 5 returned. [1278911.968046] XFS (sda1): xfs_log_force: error 5 returned. [1278942.048037] XFS (sda1): xfs_log_force: error 5 returned. [1278972.128049] XFS (sda1): xfs_log_force: error 5 returned. [1279002.208042] XFS (sda1): xfs_log_force: error 5 returned. [1279028.046331] XFS (sda1): xfs_log_force: error 5 returned. [1279028.046349] XFS (sda1): xfs_do_force_shutdown(0x1) called from line 1031 of file /home/abuild/rpmbuild/BUIL D/kernel-default-3.4.47/linux-3.4/fs/xfs/xfs_buf.c. Return address = 0xe3c813c0 [1279028.060676] XFS (sda1): xfs_log_force: error 5 returned. [1279028.067532] XFS (sda1): xfs_log_force: error 5 returned. Here's me mounting and umounting, with the xfs_repair runs in the middle: [1279032.147391] XFS (sda1): Mounting Filesystem [1279032.305924] XFS (sda1): Starting recovery (logdev: internal) [1279035.263630] XFS (sda1): Ending recovery (logdev: internal) [1279238.566041] XFS (sda1): Mounting Filesystem [1279238.713051] XFS (sda1): Ending clean mount [1279286.829764] XFS (sda1): Mounting Filesystem [1279286.982409] XFS (sda1): Ending clean mount [1279368.607644] XFS (sda1): Mounting Filesystem [1279368.755048] XFS (sda1): Ending clean mount Second time: [1279388.664986] c1516000: 41 42 54 43 00 00 00 04 df ff ff ff ff ff ff ff ABTC............ [1279388.665000] XFS (sda1): Internal error xfs_btree_check_sblock at line 119 of file /home/abuild/rpmbuild/BUI LD/kernel-default-3.4.47/linux-3.4/fs/xfs/xfs_btree.c. Caller 0xe3caf3a5 [1279388.665004] [1279388.665010] Pid: 18452, comm: rm Not tainted 3.4.47-2.38-default #1 [1279388.665015] Call Trace: [1279388.665045] [<c0205349>] try_stack_unwind+0x199/0x1b0 [1279388.665058] [<c02041c7>] dump_trace+0x47/0xf0 [1279388.665067] [<c02053ab>] show_trace_log_lvl+0x4b/0x60 [1279388.665075] [<c02053d8>] show_trace+0x18/0x20 [1279388.665086] [<c06825ba>] dump_stack+0x6d/0x72 [1279388.665211] [<e3c826ed>] xfs_corruption_error+0x5d/0x90 [xfs] [1279388.665327] [<e3cae9f4>] xfs_btree_check_sblock+0x74/0x100 [xfs] [1279388.665511] [<e3caf3a5>] xfs_btree_read_buf_block.constprop.24+0x95/0xb0 [xfs] [1279388.665684] [<e3caf423>] xfs_btree_lookup_get_block+0x63/0xc0 [xfs] [1279388.665856] [<e3cb251a>] xfs_btree_lookup+0x9a/0x460 [xfs] [1279388.666029] [<e3c97691>] xfs_alloc_ag_vextent_size+0x51/0x670 [xfs] [1279388.666163] [<e3c9874f>] xfs_alloc_ag_vextent+0x9f/0x100 [xfs] [1279388.666298] [<e3c9899a>] xfs_alloc_fix_freelist+0x1ea/0x450 [xfs] [1279388.666433] [<e3c98cd5>] xfs_free_extent+0xd5/0x160 [xfs] [1279388.666571] [<e3ca9f4e>] xfs_bmap_finish+0x15e/0x1b0 [xfs] [1279388.666734] [<e3cc47e9>] xfs_itruncate_extents+0x159/0x2f0 [xfs] [1279388.666944] [<e3c92ff5>] xfs_inactive+0x335/0x4a0 [xfs] [1279388.667039] [<c0337e84>] evict+0x84/0x150 [1279388.667053] [<c032ea22>] do_unlinkat+0x102/0x160 [1279388.667069] [<c069331c>] sysenter_do_call+0x12/0x28 [1279388.667100] [<b772f430>] 0xb772f42f [1279388.667105] XFS (sda1): Corruption detected. Unmount and run xfs_repair [1279388.667120] XFS (sda1): xfs_do_force_shutdown(0x8) called from line 3732 of file /home/abuild/rpmbuild/BUIL D/kernel-default-3.4.47/linux-3.4/fs/xfs/xfs_bmap.c. Return address = 0xe3ca9f8c [1279388.690497] XFS (sda1): Corruption of in-memory data detected. Shutting down filesystem [1279388.690506] XFS (sda1): Please umount the filesystem and rectify the problem(s) [1279398.816060] XFS (sda1): xfs_log_force: error 5 returned. [1279428.832065] XFS (sda1): xfs_log_force: error 5 returned. [ ... ] It's not entirely clear to me whether this problem is specific inodes that are corrupt or not, or just something in the filesystem header. Kernel: Linux duckling 3.4.47-2.38-default #1 SMP Fri May 31 20:17:40 UTC 2013 (3961086) i686 athlon i386 GNU/Linux progs: xfsprogs-3.1.6-9.1.2.i586 Worst case, if I can't get these to behave, I'll just beg, borrow or steal a spare 3T and copy everything to it, and then redo the FSs on these 2 drives, but it would a bit easier if I could get them to settle down a bit... Anyone have any suggestions as to which mole I should whack next? [ ... ] Built xfsprogs 3.1.11 from GIT, and ran it, and on /appl/media4, /dev/sda1: ============ duckling:/appl/downloads/xfsprogs # xfs_repair /dev/sda1 Phase 1 - find and verify superblock... Not enough RAM available for repair to enable prefetching. This will be _slow_. You need at least 497MB RAM to run with prefetching enabled. Phase 2 - using internal log - zero log... - scan filesystem freespace and inode maps... ir_freecount/free mismatch, inode chunk 2/128, freecount 62 nfree 61 ir_freecount/free mismatch, inode chunk 3/128, freecount 36 nfree 35 xfs_allocbt_read_verify: XFS_CORRUPTION_ERROR xfs_allocbt_read_verify: XFS_CORRUPTION_ERROR xfs_allocbt_read_verify: XFS_CORRUPTION_ERROR xfs_allocbt_read_verify: XFS_CORRUPTION_ERROR xfs_allocbt_read_verify: XFS_CORRUPTION_ERROR - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 imap claims a free inode 1073742013 is in use, correcting imap and clearing inode cleared inode 1073742013 - agno = 3 imap claims a free inode 1610612893 is in use, correcting imap and clearing inode cleared inode 1610612893 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - agno = 11 - agno = 12 - agno = 13 - agno = 14 - agno = 15 - agno = 16 - agno = 17 - agno = 18 - agno = 19 - agno = 20 - agno = 21 - agno = 22 - agno = 23 - agno = 24 - agno = 25 - agno = 26 - agno = 27 - agno = 28 - agno = 29 - agno = 30 - agno = 31 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - agno = 11 - agno = 12 - agno = 13 - agno = 14 - agno = 15 - agno = 16 - agno = 17 - agno = 18 - agno = 19 - agno = 20 - agno = 21 - agno = 22 - agno = 23 - agno = 24 - agno = 25 - agno = 26 - agno = 27 - agno = 28 - agno = 29 - agno = 30 - agno = 31 Phase 5 - rebuild AG headers and trees... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - traversing filesystem ... __read_verify: XFS_CORRUPTION_ERROR can't read leaf block 8388608 for directory inode 128 rebuilding directory inode 128 name create failed in ino 128 (117), filesystem may be out of space - traversal finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify and correct link counts... done ============ It's not clear to me whether that actually fixed anything or not, but I think I'm going to put off a second run, or a run on the other FS which threw more CORRUPTION errors in a later stage, until I have a better idea what's going on... Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: XFS recovery resumes... 2013-08-18 21:38 ` Jay Ashworth @ 2013-08-18 21:51 ` Joe Landman 2013-08-18 22:11 ` Jay Ashworth 2013-08-18 22:06 ` Stan Hoeppner 1 sibling, 1 reply; 23+ messages in thread From: Joe Landman @ 2013-08-18 21:51 UTC (permalink / raw) To: xfs On 08/18/2013 05:38 PM, Jay Ashworth wrote: > I'm trying to dedupe the two large XFS filesystems on which I have DVR > recordings, so that I can walk around amongst the available HDDs and create > new filesystems under everything. [...] > duckling:/appl/downloads/xfsprogs # xfs_repair /dev/sda1 > Phase 1 - find and verify superblock... > Not enough RAM available for repair to enable prefetching. > This will be _slow_. > You need at least 497MB RAM to run with prefetching enabled. ^^^^^ This is 1/2 GB ram, and you didn't specify the memory options of the xfs_repair ... so I'm going to guess at this point that you ran out of ram. Paging while running xfs_repair is no fun. How much ram do you have in this box? Next question is, is this an ECC memory box? Not sure if you are hitting a bug as much as running into something else like a hardware limit (RAM) or a memory stick issue. Do you have EDAC (or mcelog) on? Any errors from this? Joe _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: XFS recovery resumes... 2013-08-18 21:51 ` Joe Landman @ 2013-08-18 22:11 ` Jay Ashworth 2013-08-18 22:57 ` Joe Landman 0 siblings, 1 reply; 23+ messages in thread From: Jay Ashworth @ 2013-08-18 22:11 UTC (permalink / raw) To: xfs ----- Original Message ----- > From: "Joe Landman" <joe.landman@gmail.com> > > You need at least 497MB RAM to run with prefetching enabled. > > ^^^^^ > > This is 1/2 GB ram, and you didn't specify the memory options of the > xfs_repair ... so I'm going to guess at this point that you ran out of > ram. Paging while running xfs_repair is no fun. > > How much ram do you have in this box? Next question is, is this an ECC > memory box? 512M. It's a *very* old KT6V based board, and when we tried to expand it several years back, it went bat-guano with any more than half a gig. > Not sure if you are hitting a bug as much as running into something > else like a hardware limit (RAM) or a memory stick issue. Well, the upstream cause was a 7 year old Antec power supply that finally died, about a month ago, slowly. > Do you have EDAC (or mcelog) on? Any errors from this? I don't have mcelog on, and no, the memory isn't registered, but a 4-pass run of Memtest+ came up clean, so I'm speculating that the *continuing* problem isn't hardware; I'm pretty sure it was just the failing 12V rail on the dying PS. I just have to clean up after it enough to get *one* of these 2 drives cleaned off, then I can make a new FS, and play musical files. Or, I may just go grab a 3TB external after all. :-) Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: XFS recovery resumes... 2013-08-18 22:11 ` Jay Ashworth @ 2013-08-18 22:57 ` Joe Landman 2013-08-18 23:21 ` Jay Ashworth 0 siblings, 1 reply; 23+ messages in thread From: Joe Landman @ 2013-08-18 22:57 UTC (permalink / raw) To: xfs On 08/18/2013 06:11 PM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Joe Landman" <joe.landman@gmail.com> > >>> You need at least 497MB RAM to run with prefetching enabled. >> >> ^^^^^ >> >> This is 1/2 GB ram, and you didn't specify the memory options of the >> xfs_repair ... so I'm going to guess at this point that you ran out of >> ram. Paging while running xfs_repair is no fun. >> >> How much ram do you have in this box? Next question is, is this an ECC >> memory box? > > 512M. It's a *very* old KT6V based board, and when we tried to expand > it several years back, it went bat-guano with any more than half a gig. Ahhh .... ok. Got it. > >> Not sure if you are hitting a bug as much as running into something >> else like a hardware limit (RAM) or a memory stick issue. > > Well, the upstream cause was a 7 year old Antec power supply that > finally died, about a month ago, slowly. Ok. I've had power supplies take down memory in the past. You might be hitting a bad memory cell courtesy of the PS. > >> Do you have EDAC (or mcelog) on? Any errors from this? > > I don't have mcelog on, and no, the memory isn't registered, but a > 4-pass run of Memtest+ came up clean, so I'm speculating that the Not registered (which is just buffered), but ECC. ECC does a parity computation on some number of bits, and provides you a rough "good/bad" binary state of a particular area of memory. If the parity bits stored don't match what is computed on read, then odds are that something is wrong. Its not foolproof, but its a good mechanism to catch potential errors. We've had cases where Memtest(*) reported everything fine, yet I was able to generate ECC errors in a few minutes by running a memory intensive app. Memtest does do some hardware exercise, but its not usually hitting memory the way apps do. That difference can be significant. This is in part why the day job stopped using memtest for testing a number of years ago. We now run heavy duty electronic structure codes, and pi/e/... computations for burn in. > *continuing* problem isn't hardware; I'm pretty sure it was just the > failing 12V rail on the dying PS. I just have to clean up after it > enough to get *one* of these 2 drives cleaned off, then I can make a > new FS, and play musical files. Ahhh ... I was running a Plex server on an old machine for a while. I had to shift over to a beefier box with ECC ram and more CPUs. Right now my Plex server has 8 cpus, 24 GB RAM, and about 1TB of disk (old). Once you start doing recoding on the fly (multi-resolution output), you need the ram and processor power. > > Or, I may just go grab a 3TB external after all. :-) If you do that, and you still hit the error, chances are you might need to swap out your MB and CPU/RAM to something newer (not to mention the PS). I'd recommend ECC based systems if at all possible. Xfs can and will get very unhappy if bits are flipped on its data structures while you are making changes to the file system. -- Joe > > Cheers, > -- jra > _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: XFS recovery resumes... 2013-08-18 22:57 ` Joe Landman @ 2013-08-18 23:21 ` Jay Ashworth 0 siblings, 0 replies; 23+ messages in thread From: Jay Ashworth @ 2013-08-18 23:21 UTC (permalink / raw) To: xfs ----- Original Message ----- > From: "Joe Landman" <joe.landman@gmail.com> > Ok. I've had power supplies take down memory in the past. You might be > hitting a bad memory cell courtesy of the PS. Possibly, though see below. > >> Do you have EDAC (or mcelog) on? Any errors from this? > > > > I don't have mcelog on, and no, the memory isn't registered, but a > > 4-pass run of Memtest+ came up clean, so I'm speculating that the > > Not registered (which is just buffered), but ECC. ECC does a parity > computation on some number of bits, and provides you a rough "good/bad" > binary state of a particular area of memory. If the parity bits stored > don't match what is computed on read, then odds are that something is > wrong. Its not foolproof, but its a good mechanism to catch potential > errors. Sure. In my experience, all ECC is registered/buffered, and no non-ECC is, so I use it as shorthand. No possible chance this northbridge would do ECC, no. :-) > We've had cases where Memtest(*) reported everything fine, yet I was > able to generate ECC errors in a few minutes by running a memory > intensive app. Memtest does do some hardware exercise, but its not > usually hitting memory the way apps do. That difference can be > significant. This is in part why the day job stopped using memtest for > testing a number of years ago. We now run heavy duty electronic > structure codes, and pi/e/... computations for burn in. Fair point. I did also run the non-+ version of Memtest, which I understand uses a different algorithm, and a couple other things I found on the UBCD, so I'm *relatively* confident I don't have a running RAM problem, though as you say, not 100%. > > *continuing* problem isn't hardware; I'm pretty sure it was just the > > failing 12V rail on the dying PS. I just have to clean up after it > > enough to get *one* of these 2 drives cleaned off, then I can make a > > new FS, and play musical files. > > Ahhh ... > > I was running a Plex server on an old machine for a while. I had to > shift over to a beefier box with ECC ram and more CPUs. Right now my > Plex server has 8 cpus, 24 GB RAM, and about 1TB of disk (old). Once > you start doing recoding on the fly (multi-resolution output), you > need the ram and processor power. > > > > > Or, I may just go grab a 3TB external after all. :-) > > If you do that, and you still hit the error, chances are you might > need to swap out your MB and CPU/RAM to something newer (not to mention the > PS). I'd recommend ECC based systems if at all possible. Xfs can and > will get very unhappy if bits are flipped on its data structures while > you are making changes to the file system. As it happens, Dave helped me clean up a mess 4 or 5 years ago, where a *wire opened up* on the PATA cable, and all my data structures had a missing bit. Ghod was that a mess. We did end up getting the drive. So assuming I can reliably read the big drive (I have a 3T, a 2T, and a 1T all with different problems), I'm going to move all the files from it to the new 3T I just bought, and then play musical files down the chain one at a time. Thank ghod the new season hasn't started yet. ;-) Thanks for the help, Joe. Oh, and the script that Stan was so worried about? It's all rm and mv commands. 5859 of them. Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: XFS recovery resumes... 2013-08-18 21:38 ` Jay Ashworth 2013-08-18 21:51 ` Joe Landman @ 2013-08-18 22:06 ` Stan Hoeppner 2013-08-19 3:55 ` Jay Ashworth 1 sibling, 1 reply; 23+ messages in thread From: Stan Hoeppner @ 2013-08-18 22:06 UTC (permalink / raw) To: Jay Ashworth; +Cc: xfs On 8/18/2013 4:38 PM, Jay Ashworth wrote: > I'm trying to dedupe the two large XFS filesystems on which I have DVR > recordings, so that I can walk around amongst the available HDDs and create > new filesystems under everything. > > Every time I rm a file, the filesystem blows up, and the driver shuts it > down. > > Some background: > > At the moment, I have 2 devices, /dev/sdd1 mounted on /appl/media4, and > /dev/sda1 mounted on /appl/media5, and a large script, created by hand- > hacking the output of a perl dupe finder script. > > The large script was mangled so that it would remove anything that was a > dupe from media4, unless the file was an unlabeled lost+found on media5, > and had a name on media4. In that case, I removed the file on media5, and > then moved it from media4 to media5. > > After the hand-hacking on the script, I sorted it to do all the rm's first, > and then all the mv's, to make sure free space when up before it went down. > > And, of course, when I ran the script, it caused the XFS driver to cough and > die, leading to error 5s and gnashing of teeth. If this script is the catalyst of your XFS problems, it seems logical that you would include said script in your trouble report, yet you did not. It's a bit foolish to assume you can't break a Linux subsystem with a poorly written program and/or in combination with a platform that isn't up to the task being asked of it. As Joe mentioned having too little RAM could be part of this problem. -- Stan _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: XFS recovery resumes... 2013-08-18 22:06 ` Stan Hoeppner @ 2013-08-19 3:55 ` Jay Ashworth 2013-08-19 6:47 ` Stan Hoeppner 0 siblings, 1 reply; 23+ messages in thread From: Jay Ashworth @ 2013-08-19 3:55 UTC (permalink / raw) To: xfs [-- Attachment #1.1: Type: text/plain, Size: 2090 bytes --] Still the same outage from 2 weeks ago, Stan; my script had nothing to do with breaking the FSs. Was a zorched power supply, almost certainly. And in fact, after 32 years adminning *nix boxes for a living, yes, I do expect that if any userland program can /corrupt/ FS internals without twiddling with /dev/sdX, either the FS is broken or the hardware is. In this case I'm quite certain it /was/ the hardware, and 85-90% confident it's fixed now. Cheers, -jra -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. Stan Hoeppner <stan@hardwarefreak.com> wrote: On 8/18/2013 4:38 PM, Jay Ashworth wrote: > I'm trying to dedupe the two large XFS filesystems on which I have DVR > recordings, so that I can walk around amongst the available HDDs and create > new filesystems under everything. > > Every time I rm a file, the filesystem blows up, and the driver shuts it > down. > > Some background: > > At the moment, I have 2 devices, /dev/sdd1 mounted on /appl/media4, and > /dev/sda1 mounted on /appl/media5, and a large script, created by hand- > hacking the output of a perl dupe finder script. > > The large script was mangled so that it would remove anything that was a > dupe from media4, unless the file was an unlabeled lost+found on media5, > and had a name on media4. In that case, I removed the file on media5, and > then moved it from media4 to media5. > > After the hand-hacking on the script, I sorted it to do all the rm's first, > and then all the mv's, to make sure free space when up before it went down. > > And, of course, when I ran the script, it caused the XFS driver to cough and > die, leading to error 5s and gnashing of teeth. If this script is the catalyst of your XFS problems, it seems logical that you would include said script in your trouble report, yet you did not. It's a bit foolish to assume you can't break a Linux subsystem with a poorly written program and/or in combination with a platform that isn't up to the task being asked of it. As Joe mentioned having too little RAM could be part of this problem. -- Stan [-- Attachment #1.2: Type: text/html, Size: 2702 bytes --] [-- Attachment #2: Type: text/plain, Size: 121 bytes --] _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: XFS recovery resumes... 2013-08-19 3:55 ` Jay Ashworth @ 2013-08-19 6:47 ` Stan Hoeppner 2013-08-24 23:43 ` Jay Ashworth 2013-08-24 23:48 ` Default mkfs parms for my DVR drive Jay Ashworth 0 siblings, 2 replies; 23+ messages in thread From: Stan Hoeppner @ 2013-08-19 6:47 UTC (permalink / raw) To: Jay Ashworth; +Cc: xfs On 8/18/2013 10:55 PM, Jay Ashworth wrote: > Still the same outage from 2 weeks ago, Stan; my script had nothing to do with breaking the FSs. Was a zorched power supply, almost certainly. Sorry I missed this in your first post Jay. > [1278872.584543] XFS (sda1): Corruption of in-memory data detected. > Shutting down filesystem Joe appears to have hit the nail on the head WRT this being a hardware problem. This error confirms it. It would appear that when the Antec PSU went South it damaged a motherboard device, possibly a VRM, probably a cap or two, or more. Maybe damaged a DRAM cell or few that work fine with memtest86+ but not with the access pattern generated by your XFS workload. I'd first try manually clocking the DIMMs down a bit, from 400 to 333, or 333 to 266, whichever is called for. IIRC that VIA Northbrige has decoupled CPU and DRAM buses so you should be able to clock the DRAM down without affecting CPU frequency. If the problem persists, swap the DIMMs if you have some on hand or can get them really cheap like $10 for a pair. If that doesn't fix it, this may be a viable inexpensive solution: http://www.newegg.com/Product/Product.aspx?Item=N82E16813186215 http://www.newegg.com/Product/Product.aspx?Item=N82E16819103888 http://www.newegg.com/Product/Product.aspx?Item=N82E16820145252 $109 to replace your central electronics complex. This is the least expensive quality set of parts with good feature set I could come up with at Newegg, to take the sting out of dropping cash on a forced upgrade. $15 more for the Foxconn AM3 board w/HDMI if you have a newer TV or AV receiver. If it all ships from the Memphis warehouse it should reach St. Petersburg in a few days, a couple more if items ship from the LA or Newark facilities. I very rarely get anything from Newark, mostly from Memphis, then and LA. -- Stan _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: XFS recovery resumes... 2013-08-19 6:47 ` Stan Hoeppner @ 2013-08-24 23:43 ` Jay Ashworth 2013-08-25 3:44 ` Stan Hoeppner 2013-08-24 23:48 ` Default mkfs parms for my DVR drive Jay Ashworth 1 sibling, 1 reply; 23+ messages in thread From: Jay Ashworth @ 2013-08-24 23:43 UTC (permalink / raw) To: xfs ----- Original Message ----- > From: "Stan Hoeppner" <stan@hardwarefreak.com> > Joe appears to have hit the nail on the head WRT this being a hardware > problem. This error confirms it. It would appear that when the Antec > PSU went South it damaged a motherboard device, possibly a VRM, probably > a cap or two, or more. Maybe damaged a DRAM cell or few that work fine > with memtest86+ but not with the access pattern generated by your XFS > workload. Well, it appears you may be right. I'd got all the data off that 3T with no read failures, and then remade the filesystem. I had to use -f because it saw the old one, but I don't know if that's pertinent here or not. Anyroad, I made the new filesystem, with whatever mkfs.xfs's defaults are for a 3T filesystem in 3.1.11, and then started rsyncing the 2TB drive onto it, so I could fix that one. Got 88GB in, and did the same thing: =========================================== Aug 22 13:34:13 duckling kernel: [67215.008867] XFS (sda1): Corruption detected. Unmount and run xfs_repair Aug 22 13:34:13 duckling kernel: [67215.008899] XFS (sda1): Internal error xfs_trans_cancel at line 1467 of file /home/abuild/rpmbuild/BUILD/kernel-default-3.4.47/linux-3.4/fs/xfs/xfs_trans.c. Caller 0xe3d9349d Aug 22 13:34:13 duckling kernel: [67215.008903] Aug 22 13:34:13 duckling kernel: [67215.008910] Pid: 4122, comm: rsync Not tainted 3.4.47-2.38-default #1 Aug 22 13:34:13 duckling kernel: [67215.008914] Call Trace: Aug 22 13:34:13 duckling kernel: [67215.008946] [<c0205349>] try_stack_unwind+0x199/0x1b0 Aug 22 13:34:13 duckling kernel: [67215.008959] [<c02041c7>] dump_trace+0x47/0xf0 Aug 22 13:34:13 duckling kernel: [67215.008968] [<c02053ab>] show_trace_log_lvl+0x4b/0x60 Aug 22 13:34:13 duckling kernel: [67215.008975] [<c02053d8>] show_trace+0x18/0x20 Aug 22 13:34:13 duckling kernel: [67215.008986] [<c06825ba>] dump_stack+0x6d/0x72 Aug 22 13:34:13 duckling kernel: [67215.009137] [<e3dd2d47>] xfs_trans_cancel+0xe7/0x110 [xfs] Aug 22 13:34:13 duckling kernel: [67215.009426] [<e3d9349d>] xfs_create+0x22d/0x570 [xfs] Aug 22 13:34:13 duckling kernel: [67215.009551] [<e3d8aafa>] xfs_vn_mknod+0x8a/0x170 [xfs] Aug 22 13:34:13 duckling kernel: [67215.009624] [<c032ce03>] vfs_create+0xa3/0x130 Aug 22 13:34:13 duckling kernel: [67215.009634] [<c032f215>] do_last+0x6b5/0x7e0 Aug 22 13:34:13 duckling kernel: [67215.009644] [<c032f42a>] path_openat+0xaa/0x360 Aug 22 13:34:13 duckling kernel: [67215.009652] [<c032f7ce>] do_filp_open+0x2e/0x80 Aug 22 13:34:13 duckling kernel: [67215.009664] [<c032133e>] do_sys_open+0xee/0x1d0 Aug 22 13:34:13 duckling kernel: [67215.009673] [<c0321450>] sys_open+0x30/0x40 Aug 22 13:34:13 duckling kernel: [67215.009687] [<c069331c>] sysenter_do_call+0x12/0x28 Aug 22 13:34:13 duckling kernel: [67215.009719] [<b76bb430>] 0xb76bb42f Aug 22 13:34:13 duckling kernel: [67215.009726] XFS (sda1): xfs_do_force_shutdown(0x8) called from line 1468 of file /home/abuild/rpmbuild/BUILD/kernel-default-3.4.47/linux-3.4/fs/xfs/xfs_trans.c. Return address = 0xe3dd2d5f Aug 22 13:34:13 duckling kernel: [67215.034952] XFS (sda1): Corruption of in-memory data detected. Shutting down filesystem Aug 22 13:34:13 duckling kernel: [67215.034966] XFS (sda1): Please umount the filesystem and rectify the problem(s) =========================================== Followed by the obligatory: Aug 22 13:35:37 duckling kernel: [67299.040080] XFS (sda1): xfs_log_force: error 5 returned. a lot. > I'd first try manually clocking the DIMMs down a bit, from 400 to 333, > or 333 to 266, whichever is called for. IIRC that VIA Northbrige has > decoupled CPU and DRAM buses so you should be able to clock the DRAM > down without affecting CPU frequency. If the problem persists, swap the > DIMMs if you have some on hand or can get them really cheap like $10 > for a pair. I'll try swapping it; this mobo has always gotten whacky if we went over 512M, which is why we haven't. I don't know if I can manually reclock the ram, though I might can turn the waitstates up. > If that doesn't fix it, this may be a viable inexpensive > solution: > > http://www.newegg.com/Product/Product.aspx?Item=N82E16813186215 > http://www.newegg.com/Product/Product.aspx?Item=N82E16819103888 > http://www.newegg.com/Product/Product.aspx?Item=N82E16820145252 > > $109 to replace your central electronics complex. This is the least > expensive quality set of parts with good feature set I could come up > with at Newegg, to take the sting out of dropping cash on a forced > upgrade. $15 more for the Foxconn AM3 board w/HDMI if you have a newer > TV or AV receiver. Well, I can live without HDMI, but my present MS-7021 mobo has 5 PCI slots, and I'm using all of them: 2 PVR-150s, a PVR-500, and a SiI 4-port raid (which will talk to 2 and 3TB drives; the motherboard SATA won't even see them). I forget what's in 5, but I think it was the only VGA card I had with S-Video out. So, while that's a damn nice price point, it will require me to buy a bunch of Ethernet tuners as well. <sigh> I'll try the RAM. It's really odd, though, that the badblocks workload and both memtests couldn't find a problem, if it is the memory plane... Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: XFS recovery resumes... 2013-08-24 23:43 ` Jay Ashworth @ 2013-08-25 3:44 ` Stan Hoeppner 2013-08-25 15:29 ` Jay Ashworth 0 siblings, 1 reply; 23+ messages in thread From: Stan Hoeppner @ 2013-08-25 3:44 UTC (permalink / raw) To: xfs On 8/24/2013 6:43 PM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Stan Hoeppner" <stan@hardwarefreak.com> > >> Joe appears to have hit the nail on the head WRT this being a hardware >> problem. This error confirms it. It would appear that when the Antec >> PSU went South it damaged a motherboard device, possibly a VRM, probably >> a cap or two, or more. Maybe damaged a DRAM cell or few that work fine >> with memtest86+ but not with the access pattern generated by your XFS >> workload. > > Well, it appears you may be right. ... > Aug 22 13:34:13 duckling kernel: [67215.034952] XFS (sda1): Corruption of in-memory data detected. Shutting down filesystem I don't see any other possibility than a hardware problem. And given the age of that hardware, it's cheaper in dollars and time to start over with new gear. > I'll try swapping it; this mobo has always gotten whacky if we went over 512M, > which is why we haven't. The manual says up to 2GB DDR2. Board has two DIMM sockets, which means 1GB DIMMs supported. If anything over 512MB (2x256MB DIMMs) causes problems then the board had a flaw, or needed a BIOS update, etc. And now it's physically damaged. > I don't know if I can manually reclock the ram, though I might can turn the > waitstates up. That probably won't help but you can try it. The manual shows the BIOS does not support independent clocking of the DRAM. >> If that doesn't fix it, this may be a viable inexpensive >> solution: >> >> http://www.newegg.com/Product/Product.aspx?Item=N82E16813186215 >> http://www.newegg.com/Product/Product.aspx?Item=N82E16819103888 >> http://www.newegg.com/Product/Product.aspx?Item=N82E16820145252 >> >> $109 to replace your central electronics complex. This is the least >> expensive quality set of parts with good feature set I could come up >> with at Newegg, to take the sting out of dropping cash on a forced >> upgrade. $15 more for the Foxconn AM3 board w/HDMI if you have a newer >> TV or AV receiver. > > Well, I can live without HDMI, but my present MS-7021 mobo has 5 PCI > slots, and I'm using all of them: 2 PVR-150s, a PVR-500, and a SiI > 4-port raid (which will talk to 2 and 3TB drives; the motherboard SATA > won't even see them). You'll be extremely hard pressed to find a current board with more than 3 PCI unless you buy used. Hmmm...let's see....here we go: http://www.newegg.com/Product/Product.aspx?Item=N82E16813135329 http://www.newegg.com/Product/Product.aspx?Item=N82E16819113283 http://www.newegg.com/Product/Product.aspx?Item=N82E16820148194 -- $155 For less than $50 more you not only get all the slots/ports you need, but also a much faster dual core CPU and GPU, plus HDMI. And you'll no longer have disks on the slow PCI bus. Looks like a winner. > I forget what's in 5, but I think it was the only VGA card I had with > S-Video out. If you absolutely need Svideo/composite output then you'll need to use an external converter or switch box, something like this: http://www.newegg.com/Product/Product.aspx?Item=9SIA0U00JZ2490 > So, while that's a damn nice price point, it will require me to buy > a bunch of Ethernet tuners as well. <sigh> Not now. ;) > I'll try the RAM. It's really odd, though, that the badblocks workload > and both memtests couldn't find a problem, if it is the memory plane... This isn't odd at all and actually quite common. The problem likely is not in the DRAM modules or individual transistors in the DRAM chips. The problem is likely unstable signalling to/from the DIMM sockets, or unstable power to the CPU or Northbridge, caused by old and now damaged power delivery circuits on the mainboard. Download and run burnp6 for 5-10 minutes. That'll tell you if the CPU is getting sufficient power. Make sure the CPU fan is in working order first. It's called BURNp6 for a reason. The Athlons didn't have thermal shutdown capability, and this will literally destroy the CPU with heat build up if the fans aren't working properly. If cooling is good, and the system hard locks or exhibits other strange behavior, then you know it's time to replace the board. But I think you know that already. This will simply be the exclamation point. -- Stan _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: XFS recovery resumes... 2013-08-25 3:44 ` Stan Hoeppner @ 2013-08-25 15:29 ` Jay Ashworth 2013-08-25 17:45 ` Stan Hoeppner 0 siblings, 1 reply; 23+ messages in thread From: Jay Ashworth @ 2013-08-25 15:29 UTC (permalink / raw) To: xfs ----- Original Message ----- > From: "Stan Hoeppner" <stan@hardwarefreak.com> > I don't see any other possibility than a hardware problem. And given > the age of that hardware, it's cheaper in dollars and time to start > over with new gear. Only if you have it, Stan. Only if you have it... > > I'll try swapping it; this mobo has always gotten whacky if we went > > over 512M, which is why we haven't. > > The manual says up to 2GB DDR2. Board has two DIMM sockets, which means > 1GB DIMMs supported. If anything over 512MB (2x256MB DIMMs) causes > problems then the board had a flaw, or needed a BIOS update, etc. And > now it's physically damaged. The BIOS was up to date when we installed it new. > You'll be extremely hard pressed to find a current board with more > than 3 PCI unless you buy used. Hmmm...let's see....here we go: I know. :-} > http://www.newegg.com/Product/Product.aspx?Item=N82E16813135329 > http://www.newegg.com/Product/Product.aspx?Item=N82E16819113283 > http://www.newegg.com/Product/Product.aspx?Item=N82E16820148194 > > -- $155 > > For less than $50 more you not only get all the slots/ports you need, > but also a much faster dual core CPU and GPU, plus HDMI. And you'll no > longer have disks on the slow PCI bus. Looks like a winner. It does. > > I forget what's in 5, but I think it was the only VGA card I had > > with > > S-Video out. > > If you absolutely need Svideo/composite output then you'll need to use > an external converter or switch box, something like this: > > http://www.newegg.com/Product/Product.aspx?Item=9SIA0U00JZ2490 I don't know if the set has HDMI in or not; it's an older Philips; 37" I think. Probably. > > I'll try the RAM. It's really odd, though, that the badblocks workload > > and both memtests couldn't find a problem, if it is the memory plane... > > This isn't odd at all and actually quite common. The problem likely is > not in the DRAM modules or individual transistors in the DRAM chips. > The problem is likely unstable signalling to/from the DIMM sockets, or > unstable power to the CPU or Northbridge, caused by old and now > damaged power delivery circuits on the mainboard. > > Download and run burnp6 for 5-10 minutes. That'll tell you if the CPU > is getting sufficient power. Make sure the CPU fan is in working order > first. It's called BURNp6 for a reason. The Athlons didn't have > thermal shutdown capability, and this will literally destroy the CPU > with heat build up if the fans aren't working properly. If cooling is > good, and the system hard locks or exhibits other strange behavior, > then you know it's time to replace the board. But I think you know that > already. This will simply be the exclamation point. Well, oddly, it's up to about 1.4TB moved now overnight, and not a whisper of an error in any channel. It does need to be replaced, but the question is can I make it limp along reliably until she gets another job... Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: XFS recovery resumes... 2013-08-25 15:29 ` Jay Ashworth @ 2013-08-25 17:45 ` Stan Hoeppner 2013-08-25 20:27 ` Jay Ashworth 0 siblings, 1 reply; 23+ messages in thread From: Stan Hoeppner @ 2013-08-25 17:45 UTC (permalink / raw) To: xfs On 8/25/2013 10:29 AM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Stan Hoeppner" <stan@hardwarefreak.com> > >> I don't see any other possibility than a hardware problem. And given >> the age of that hardware, it's cheaper in dollars and time to start >> over with new gear. > > Only if you have it, Stan. Only if you have it... True, that. >>> I'll try swapping it; this mobo has always gotten whacky if we went >>> over 512M, which is why we haven't. >> >> The manual says up to 2GB DDR2. Board has two DIMM sockets, which means >> 1GB DIMMs supported. If anything over 512MB (2x256MB DIMMs) causes >> problems then the board had a flaw, or needed a BIOS update, etc. And >> now it's physically damaged. > > The BIOS was up to date when we installed it new. > >> You'll be extremely hard pressed to find a current board with more >> than 3 PCI unless you buy used. Hmmm...let's see....here we go: > > I know. :-} > >> http://www.newegg.com/Product/Product.aspx?Item=N82E16813135329 >> http://www.newegg.com/Product/Product.aspx?Item=N82E16819113283 >> http://www.newegg.com/Product/Product.aspx?Item=N82E16820148194 >> >> -- $155 >> >> For less than $50 more you not only get all the slots/ports you need, >> but also a much faster dual core CPU and GPU, plus HDMI. And you'll no >> longer have disks on the slow PCI bus. Looks like a winner. > > It does. > >>> I forget what's in 5, but I think it was the only VGA card I had >>> with >>> S-Video out. >> >> If you absolutely need Svideo/composite output then you'll need to use >> an external converter or switch box, something like this: >> >> http://www.newegg.com/Product/Product.aspx?Item=9SIA0U00JZ2490 > > I don't know if the set has HDMI in or not; it's an older Philips; 37" > I think. Probably. The board has VGA, DVI, and HDMI, so you should be covered six ways to Sunday with flat panel displays. If this Philips is an older "fork lift required" 37" CRT then it probably only has composite, Svideo, maybe component. >>> I'll try the RAM. It's really odd, though, that the badblocks workload >>> and both memtests couldn't find a problem, if it is the memory plane... >> >> This isn't odd at all and actually quite common. The problem likely is >> not in the DRAM modules or individual transistors in the DRAM chips. >> The problem is likely unstable signalling to/from the DIMM sockets, or >> unstable power to the CPU or Northbridge, caused by old and now >> damaged power delivery circuits on the mainboard. >> >> Download and run burnp6 for 5-10 minutes. That'll tell you if the CPU >> is getting sufficient power. Make sure the CPU fan is in working order >> first. It's called BURNp6 for a reason. The Athlons didn't have >> thermal shutdown capability, and this will literally destroy the CPU >> with heat build up if the fans aren't working properly. If cooling is >> good, and the system hard locks or exhibits other strange behavior, >> then you know it's time to replace the board. But I think you know that >> already. This will simply be the exclamation point. > > Well, oddly, it's up to about 1.4TB moved now overnight, and not a whisper > of an error in any channel. It does need to be replaced, but the question > is can I make it limp along reliably until she gets another job... Just keep fingers/toes crossed. That mobo is nearly 10 years old, never handled RAM correctly. You suffered a PSU failure which apparently damaged something to some degree. But you now know there are relatively inexpensive upgrade options available with the features you need, and you can begin planning, while not in "emergency mode" with sis hounding you every day to fix it. ;) -- Stan _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: XFS recovery resumes... 2013-08-25 17:45 ` Stan Hoeppner @ 2013-08-25 20:27 ` Jay Ashworth 2013-08-26 5:45 ` Stan Hoeppner 0 siblings, 1 reply; 23+ messages in thread From: Jay Ashworth @ 2013-08-25 20:27 UTC (permalink / raw) To: xfs ----- Original Message ----- > The board has VGA, DVI, and HDMI, so you should be covered six ways to > Sunday with flat panel displays. If this Philips is an older "fork lift > required" 37" CRT then it probably only has composite, Svideo, maybe > component. I *think* it has HDMI in, I just didn't have any HDMI capable VGA cards at the time, so I moved on to something else in my head. > > Well, oddly, it's up to about 1.4TB moved now overnight, and not a > > whisper > > of an error in any channel. It does need to be replaced, but the > > question > > is can I make it limp along reliably until she gets another job... > > Just keep fingers/toes crossed. That mobo is nearly 10 years old, > never handled RAM correctly. You suffered a PSU failure which apparently > damaged something to some degree. But you now know there are relatively > inexpensive upgrade options available with the features you need, and > you can begin planning, while not in "emergency mode" with sis > hounding you every day to fix it. ;) This is the second Major Catastrophe in about 8 years, so we've gotten settled a bit that she takes second position if she can't pay my rate. :-) But yes, an upgrade was planned; I just wanted to upgrade the damn tuners first... Thanks for the homework with NewEgg; I don't mind buying stuff from them as long as it isn't HDDs. They can't pack worth a crap; it's Received Wisdom on the MythTV mailing list that you *never* buy drives from them, if you want them to last more than a year. My endgame is to replace the entire backend with an HP DL180g6, which has 12 SAS/SATA tray slots on the front, and proper cooling. But that, too, is down the road a bit. Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: XFS recovery resumes... 2013-08-25 20:27 ` Jay Ashworth @ 2013-08-26 5:45 ` Stan Hoeppner 2013-08-26 15:42 ` Jay Ashworth 0 siblings, 1 reply; 23+ messages in thread From: Stan Hoeppner @ 2013-08-26 5:45 UTC (permalink / raw) To: xfs On 8/25/2013 3:27 PM, Jay Ashworth wrote: ... > But yes, an upgrade was planned; I just wanted to upgrade the damn tuners > first... I'm not really into the DIY DVR scene, but I'd think with over the air, cable, and sat all being digital now that you should be able to get a single board to do the job, multi-channel simultaneous recording and all. > Thanks for the homework with NewEgg; No problem. I have a rep to maintain after all. Maybe you didn't notice the right hand side of my email address. :) > I don't mind buying stuff from > them as long as it isn't HDDs. They can't pack worth a crap; it's > Received Wisdom on the MythTV mailing list that you *never* buy > drives from them, if you want them to last more than a year. Hadn't heard that before. I've never had a problem with any of the spinning drives I purchased from them. I had a Corsair SSD die after ~4 months, no fault of Newegg. Of the few grand I've spent with them since 2003, on parts for many new systems, repairs and upgrades, the only other problem I've had was a $20 four channel fan controller w/one dead channel outta the box. > My endgame is to replace the entire backend with an HP DL180g6, which > has 12 SAS/SATA tray slots on the front, and proper cooling. But that, > too, is down the road a bit. Are you still talking about your sister's DVR here? Build another PC and spend some of the $$ you'd save on a 65" Panasonic Plasma. Save the rest for a rainy day. The DL180G6 (discontinued BTW) with a handful of drives will cost more than the PC and plasma TV combined. -- Stan _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: XFS recovery resumes... 2013-08-26 5:45 ` Stan Hoeppner @ 2013-08-26 15:42 ` Jay Ashworth 0 siblings, 0 replies; 23+ messages in thread From: Jay Ashworth @ 2013-08-26 15:42 UTC (permalink / raw) To: xfs ----- Original Message ----- > From: "Stan Hoeppner" <stan@hardwarefreak.com> > I'm not really into the DIY DVR scene, but I'd think with over the air, > cable, and sat all being digital now that you should be able to get a > single board to do the job, multi-channel simultaneous recording and > all. These days, that's the Ceton InfiniTV or the Silicon Dust HDHomeRun, both of which are Ethernet-attach, and take zero slots. And, alas, the other implication of unemployment and poverty is "analog only cable". > > Thanks for the homework with NewEgg; > > No problem. I have a rep to maintain after all. Maybe you didn't > notice the right hand side of my email address. :) Heh. > > I don't mind buying stuff from > > them as long as it isn't HDDs. They can't pack worth a crap; it's > > Received Wisdom on the MythTV mailing list that you *never* buy > > drives from them, if you want them to last more than a year. > > Hadn't heard that before. I've never had a problem with any of the > spinning drives I purchased from them. I had a Corsair SSD die after ~4 > months, no fault of Newegg. Of the few grand I've spent with them since > 2003, on parts for many new systems, repairs and upgrades, the only > other problem I've had was a $20 four channel fan controller w/one > dead channel outta the box. Things may have changed, but one of these ST3000s we're talking about came by UPS fom TigerDirect... wrapped in one wrap of heavy kraft, and nothing else. Happily, their local retail store swapped it for me, for one that came in in proper packaging, without trouble. > > My endgame is to replace the entire backend with an HP DL180g6, > > which > > has 12 SAS/SATA tray slots on the front, and proper cooling. But > > that, > > too, is down the road a bit. > > Are you still talking about your sister's DVR here? Build another PC > and spend some of the $$ you'd save on a 65" Panasonic Plasma. Save the > rest for a rainy day. The DL180G6 (discontinued BTW) with a handful of > drives will cost more than the PC and plasma TV combined. Because it's discontinued, the secondary market price is about $200, and the 12 tray slots on the front will take the SATA drives I already have; why I picked it. Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 23+ messages in thread
* Default mkfs parms for my DVR drive 2013-08-19 6:47 ` Stan Hoeppner 2013-08-24 23:43 ` Jay Ashworth @ 2013-08-24 23:48 ` Jay Ashworth 2013-08-25 0:00 ` Joe Landman 1 sibling, 1 reply; 23+ messages in thread From: Jay Ashworth @ 2013-08-24 23:48 UTC (permalink / raw) To: xfs This is a Seagate ST3000DM001, all one volume, for my sister's DVR on which I've been doing this volume recovery work. The default setup that mkfs.xfs returns with no parms supplies is this: meta-data=/dev/sda1 isize=256 agcount=4, agsize=183141568 blks = sectsz=4096 attr=2, projid32bit=0 data = bsize=4096 blocks=732566272, imaxpct=5 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0 log =internal log bsize=4096 blocks=357698, version=2 = sectsz=4096 sunit=1 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0 and that takes about 3 minutes to mkfs a 3TB drive. Anyone have some thoughts they wish to cast upon the waters about either part of that? Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Default mkfs parms for my DVR drive 2013-08-24 23:48 ` Default mkfs parms for my DVR drive Jay Ashworth @ 2013-08-25 0:00 ` Joe Landman 2013-08-25 0:41 ` Jay Ashworth 0 siblings, 1 reply; 23+ messages in thread From: Joe Landman @ 2013-08-25 0:00 UTC (permalink / raw) To: xfs On 08/24/2013 07:48 PM, Jay Ashworth wrote: > This is a Seagate ST3000DM001, all one volume, for my sister's DVR on > which I've been doing this volume recovery work. The default setup that > mkfs.xfs returns with no parms supplies is this: > > meta-data=/dev/sda1 isize=256 agcount=4, agsize=183141568 blks > = sectsz=4096 attr=2, projid32bit=0 > data = bsize=4096 blocks=732566272, imaxpct=5 > = sunit=0 swidth=0 blks > naming =version 2 bsize=4096 ascii-ci=0 > log =internal log bsize=4096 blocks=357698, version=2 > = sectsz=4096 sunit=1 blks, lazy-count=1 > realtime =none extsz=4096 blocks=0, rtextents=0 > > and that takes about 3 minutes to mkfs a 3TB drive. > > Anyone have some thoughts they wish to cast upon the waters about either part > of that? Dave, Eric, and the rest of the xfs team will tell you "use the defaults Luke". For 99 and 44/100ths percent of users, this is the right choice. I am guessing that some of the delay may be the speed of the interface to the disk ... but even then 3 minutes sounds long, unless something else is hitting the disk at the same time. Which kernel version btw? A quick 'uname -a' is a good thing. Your hardware could also be somewhat slow ... Could you do an lshw -class disk -class storage _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Default mkfs parms for my DVR drive 2013-08-25 0:00 ` Joe Landman @ 2013-08-25 0:41 ` Jay Ashworth 2013-08-25 3:41 ` Jay Ashworth 0 siblings, 1 reply; 23+ messages in thread From: Jay Ashworth @ 2013-08-25 0:41 UTC (permalink / raw) To: xfs ---- Original Message ----- > From: "Joe Landman" <joe.landman@gmail.com> > Dave, Eric, and the rest of the xfs team will tell you "use the defaults > Luke". For 99 and 44/100ths percent of users, this is the right choice. Well, if I can't; they're the ones who screwed up. :-) > I am guessing that some of the delay may be the speed of the interface > to the disk ... but even then 3 minutes sounds long, unless something > else is hitting the disk at the same time. > > Which kernel version btw? A quick 'uname -a' is a good thing. Ok, ok; this isn't the same thread anymore. :-) Linux duckling 3.4.47-2.38-default #1 SMP Fri May 31 20:17:40 UTC 2013 (3961086) i686 athlon i386 GNU/Linux > Your hardware could also be somewhat slow ... Could you do an > > lshw -class disk -class storage It probably is. It's an old Athlon, MSI MS-7021, KT6V chipset; 512M of DDR... maybe that's DDR 2; it won't run right with more. I don't seem to have lshw. Or, oddly, hwconfig. It's got 3 Seagate ST3000DM001s, 2 on a SiI 7114 PCI with a pair of Fujitsu Deskstars, 2T and 1T; 40G Samsung boot on the mobo SATA; the third 3000 is in a USB 2 enclosure. And this latest rsync has gotten 78G and then paused; 80G and then paused.... 84G and then paused... 5 min LA 1.9, and the rsync is the top process. I have smartd running; no errors yet. Still watching... Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Default mkfs parms for my DVR drive 2013-08-25 0:41 ` Jay Ashworth @ 2013-08-25 3:41 ` Jay Ashworth 0 siblings, 0 replies; 23+ messages in thread From: Jay Ashworth @ 2013-08-25 3:41 UTC (permalink / raw) To: xfs ----- Original Message ----- > From: "Jay Ashworth" <jra@baylink.com> > And this latest rsync has gotten 78G and then paused; 80G and then > paused.... > > 84G and then paused... > > 5 min LA 1.9, and the rsync is the top process. > > I have smartd running; no errors yet. > > Still watching... Well, it's now up to 377GB, and it hasn't crashed yet. Since the original FSs and the new one were mkfs'd by different versions of the mkfs program, I suppose it's possible that might have contributed to the crash in some perverted way that running badblocks -w in the middle would definitely prevent. We'll see if it survives the night. Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: XFS recovery resumes... 2013-08-11 22:36 ` XFS recovery resumes Jay Ashworth 2013-08-18 21:38 ` Jay Ashworth @ 2013-08-22 9:16 ` Stefan Ring 2013-08-27 23:59 ` Dave Chinner 1 sibling, 1 reply; 23+ messages in thread From: Stefan Ring @ 2013-08-22 9:16 UTC (permalink / raw) To: Jay Ashworth; +Cc: Linux fs XFS On Mon, Aug 12, 2013 at 12:36 AM, Jay Ashworth <jra@baylink.com> wrote: > (and I apologize that I can't copy that in; I was running under screen, and > it doesn't cooperate with scrollback well). Running inside screen is perfect for conserving scrollback, although actually getting it out is a bit tedious: - Enter copy mode: Ctrl-a Ctrl-[ (moving around: Pg-Up/Pg-Down via Ctrl-B/Ctrl-F) - Mark a selection: SPC + moving up or down - Yank: Y - Write to file: Ctrl-a :writebuf /tmp/scrlog I also tend to have this in my ~/.screenrc: defscrollback 20000 _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: XFS recovery resumes... 2013-08-22 9:16 ` XFS recovery resumes Stefan Ring @ 2013-08-27 23:59 ` Dave Chinner 2013-08-28 0:19 ` Jay Ashworth 0 siblings, 1 reply; 23+ messages in thread From: Dave Chinner @ 2013-08-27 23:59 UTC (permalink / raw) To: Stefan Ring; +Cc: Jay Ashworth, Linux fs XFS On Thu, Aug 22, 2013 at 11:16:18AM +0200, Stefan Ring wrote: > On Mon, Aug 12, 2013 at 12:36 AM, Jay Ashworth <jra@baylink.com> wrote: > > (and I apologize that I can't copy that in; I was running under screen, and > > it doesn't cooperate with scrollback well). > > Running inside screen is perfect for conserving scrollback, although > actually getting it out is a bit tedious: > > - Enter copy mode: Ctrl-a Ctrl-[ (moving around: Pg-Up/Pg-Down via > Ctrl-B/Ctrl-F) > - Mark a selection: SPC + moving up or down > - Yank: Y > - Write to file: Ctrl-a :writebuf /tmp/scrlog > > I also tend to have this in my ~/.screenrc: > > defscrollback 20000 Add this to your ~/.screenrc: termcapinfo xterm|xterms|xs|rxvt ti@:te@ And screen will write to the terminal's scrollback buffer rather than it's own internal buffer. Cheers, Dave. -- Dave Chinner david@fromorbit.com _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: XFS recovery resumes... 2013-08-27 23:59 ` Dave Chinner @ 2013-08-28 0:19 ` Jay Ashworth 0 siblings, 0 replies; 23+ messages in thread From: Jay Ashworth @ 2013-08-28 0:19 UTC (permalink / raw) To: xfs ----- Original Message ----- > From: "Dave Chinner" <david@fromorbit.com> > Add this to your ~/.screenrc: > > termcapinfo xterm|xterms|xs|rxvt ti@:te@ > > And screen will write to the terminal's scrollback buffer rather > than it's own internal buffer. Well, sure, but only from whatever screen is active, and they'll all get mixed together. There's no real good answer to it... -- j -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~2013-08-28 0:20 UTC | newest]
Thread overview: 23+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <29874428.3384.1376259762936.JavaMail.root@benjamin.baylink.com>
2013-08-11 22:36 ` XFS recovery resumes Jay Ashworth
2013-08-18 21:38 ` Jay Ashworth
2013-08-18 21:51 ` Joe Landman
2013-08-18 22:11 ` Jay Ashworth
2013-08-18 22:57 ` Joe Landman
2013-08-18 23:21 ` Jay Ashworth
2013-08-18 22:06 ` Stan Hoeppner
2013-08-19 3:55 ` Jay Ashworth
2013-08-19 6:47 ` Stan Hoeppner
2013-08-24 23:43 ` Jay Ashworth
2013-08-25 3:44 ` Stan Hoeppner
2013-08-25 15:29 ` Jay Ashworth
2013-08-25 17:45 ` Stan Hoeppner
2013-08-25 20:27 ` Jay Ashworth
2013-08-26 5:45 ` Stan Hoeppner
2013-08-26 15:42 ` Jay Ashworth
2013-08-24 23:48 ` Default mkfs parms for my DVR drive Jay Ashworth
2013-08-25 0:00 ` Joe Landman
2013-08-25 0:41 ` Jay Ashworth
2013-08-25 3:41 ` Jay Ashworth
2013-08-22 9:16 ` XFS recovery resumes Stefan Ring
2013-08-27 23:59 ` Dave Chinner
2013-08-28 0:19 ` Jay Ashworth
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox