<div dir="ltr">Hi all, <div><br></div><div>We may hit this bug in OpenStack Swift :</div>Race condition quarantines valid objects <a href="https://bugs.launchpad.net/swift/+bug/1451520">https://bugs.launchpad.net/swift/+bug/1451520</a><div><br></div><div>This race condition may cause the problem which Brain mentioned previously. OpenStack community fixed this in Swift's code. Should it be a kernel bug of XFS too ? </div><div><br></div><div>Thanks for all your efforts. </div><div>Hugo</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-07-14 2:10 GMT+08:00 Kuo Hugo <span dir="ltr"><<a href="mailto:tonytkdk@gmail.com" target="_blank">tonytkdk@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Brain, <div><br></div><div>The sdb is mounted on /srv/node/d224 on this server. That's one of three disks that the process was making I/O on it. </div><div>Those openfiles on /srv/node/d224 were made by the process to storing/deleting data at that moment while the kernel panic appeared. </div><div><br></div><div>```</div><span class=""><div><span style="font-family:Consolas,Inconsolata,Courier,monospace;font-size:11.8999996185303px;line-height:16.8000011444092px;white-space:pre-wrap;background-color:rgb(248,248,248)"> 36 ffff8808703ed6c0 ffff88086fd65540 ffff8805eb03ed88 REG /srv/node/d205/quarantined/</span><span style="font-family:Consolas,Inconsolata,Courier,monospace;font-size:11.8999996185303px;line-height:16.8000011444092px;white-space:pre-wrap;background-color:rgb(248,248,248)">objects/</span><span style="font-family:Consolas,Inconsolata,Courier,monospace;font-size:11.8999996185303px;line-height:16.8000011444092px;white-space:pre-wrap;background-color:rgb(248,248,248)">cd1d68f515006d443a54ff4f658091</span><span style="font-family:Consolas,Inconsolata,Courier,monospace;font-size:11.8999996185303px;line-height:16.8000011444092px;white-space:pre-wrap;background-color:rgb(248,248,248)">bc-</span><span style="font-family:Consolas,Inconsolata,Courier,monospace;font-size:11.8999996185303px;line-height:16.8000011444092px;white-space:pre-wrap;background-color:rgb(248,248,248)">a114bba1449b45238abf38dc741d7c</span><span style="font-family:Consolas,Inconsolata,Courier,monospace;font-size:11.8999996185303px;line-height:16.8000011444092px;white-space:pre-wrap;background-color:rgb(248,248,248)">27/1436254020.89801.ts
37 ffff8810718343c0 ffff88105b9d32c0 ffff8808745aa5e8 REG [eventpoll]
38 ffff8808713da780 ffff880010c9a900 ffff88096368a188 REG /srv/node/d224/quarantined/</span><span style="font-family:Consolas,Inconsolata,Courier,monospace;font-size:11.8999996185303px;line-height:16.8000011444092px;white-space:pre-wrap;background-color:rgb(248,248,248)">objects/</span><span style="font-family:Consolas,Inconsolata,Courier,monospace;font-size:11.8999996185303px;line-height:16.8000011444092px;white-space:pre-wrap;background-color:rgb(248,248,248)">b146865bf8034bfc42570b747c341b</span><span style="font-family:Consolas,Inconsolata,Courier,monospace;font-size:11.8999996185303px;line-height:16.8000011444092px;white-space:pre-wrap;background-color:rgb(248,248,248)">32/1436266042.57775.ts
39 ffff880871cb03c0 ffff880495a8b380 ffff8808a5e6c988 REG /srv/node/d224/tmp/tmpSpnrHg
40 ffff8808715b4540 ffff8804819c58c0 ffff8802381f8d88 DIR /srv/node/d224/quarantined/</span><span style="font-family:Consolas,Inconsolata,Courier,monospace;font-size:11.8999996185303px;line-height:16.8000011444092px;white-space:pre-wrap;background-color:rgb(248,248,248)">objects/</span><span style="font-family:Consolas,Inconsolata,Courier,monospace;font-size:11.8999996185303px;line-height:16.8000011444092px;white-space:pre-wrap;background-color:rgb(248,248,248)">b146865bf8034bfc42570b747c341b</span><span style="font-family:Consolas,Inconsolata,Courier,monospace;font-size:11.8999996185303px;line-height:16.8000011444092px;white-space:pre-wrap;background-color:rgb(248,248,248)">32</span><br></div></span><div>```</div><div><br></div><div>I'll check the dir location of the inode number. </div><div><br></div><div>Nice information. </div><div><br></div><div>Thanks // Hugo </div></div><div class="gmail_extra"><br><div class="gmail_quote"><span class="">2015-07-14 1:01 GMT+08:00 Brian Foster <span dir="ltr"><<a href="mailto:bfoster@redhat.com" target="_blank">bfoster@redhat.com</a>></span>:<br></span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><span>On Mon, Jul 13, 2015 at 10:06:39PM +0800, Kuo Hugo wrote:<br>
> Hi Brain,<br>
><br>
</span></span><span><span class="">> Sorry for the wrong file in previous message. I believe this the right one.<br>
><br></span>
> <a href="https://cloud.swiftstack.com/v1/AUTH_hugo/public/xfs.ko.debug" rel="noreferrer" target="_blank">https://cloud.swiftstack.com/v1/AUTH_hugo/public/xfs.ko.debug</a><br>
><br>
> /usr/lib/debug/lib/modules/2.6.32-504.23.4.el6.x86_64/kernel/fs/xfs/xfs.ko.debug<br>
><br>
> MD5 : 27829c9c55f4f5b095d29a7de7c27254<br>
><br>
<br>
</span><div><div class="h5">Yes, that works. I have a few bits of information so far, but nothing<br>
obvious to me as to what caused the problem. Some info:<br>
<br>
- The crash is indeed at xfs_dir2_sf_get_inumber():<br>
<br>
/usr/src/debug/kernel-2.6.32-504.23.4.el6/linux-2.6.32-504.23.4.el6.x86_64/fs/xfs/xfs_dir2_sf.h: 101<br>
0xffffffffa0362d60 <xfs_dir2_sf_getdents+672>: cmpb $0x0,0x1(%r12)<br>
...<br>
<br>
- %r12 above has a value of 0 and is set as follows:<br>
<br>
/usr/src/debug/kernel-2.6.32-504.23.4.el6/linux-2.6.32-504.23.4.el6.x86_64/fs/xfs/xfs_dir2_sf.c: 727<br>
0xffffffffa0362b11 <xfs_dir2_sf_getdents+81>: mov 0x50(%rdi),%r12<br>
<br>
... which is the sfp pointer assignment in the getdents function:<br>
<br>
sfp = (xfs_dir2_sf_t *)dp->i_df.if_u1.if_data;<br>
<br>
This implies a NULL if_data.<br>
<br>
- The backtrace lists a couple of inodes on the stack in this frame. I'm<br>
not sure why, but one looks like a valid directory and the other looks<br>
bogus. The valid inode has an inode number of 13668207561.<br>
<br>
- The fsname for this inode is "sdb."<br>
<br>
- The inode does appear to have a non-NULL if_data:<br>
<br>
...<br>
if_u1 = {<br>
if_extents = 0xffff88084feaf5c0,<br>
if_ext_irec = 0xffff88084feaf5c0,<br>
if_data = 0xffff88084feaf5c0 "\004"<br>
},<br>
...<br>
<br>
So it's not totally clear what's going on there. It might be interesting<br>
to see what directory this refers to, if it still exists on the sdb fs.<br>
For example, is it an external directory or some kind of internal<br>
directory created by the application? You could use something like the<br>
following to try and locate the directory based on inode number:<br>
<br>
find <mntpath> -inum 13668207561<br>
<span><font color="#888888"><br>
Brian<br>
</font></span></div></div><div><div><br>
> Thanks // Hugo<span class=""><br>
> <br>
><br>
> 2015-07-13 20:52 GMT+08:00 Brian Foster <<a href="mailto:bfoster@redhat.com" target="_blank">bfoster@redhat.com</a>>:<br>
><br>
> > On Fri, Jul 10, 2015 at 01:36:41PM +0800, Kuo Hugo wrote:<br>
> > > Hi Brain,<br>
> > ><br>
> > > Is this the file which you need ?<br>
> > ><br></span>
> > > <a href="https://cloud.swiftstack.com/v1/AUTH_hugo/public/xfs.ko" rel="noreferrer" target="_blank">https://cloud.swiftstack.com/v1/AUTH_hugo/public/xfs.ko</a><span class=""><br>
> > ><br>
> > > $> modinfo xfs<br>
> > ><br>
> > > filename: /lib/modules/2.6.32-504.23.4.el6.x86_64/kernel/fs/xfs/xfs.ko<br>
> > > license: GPL<br>
> > > description: SGI XFS with ACLs, security attributes, large block/inode<br>
> > > numbers, no debug enabled<br>
> > > author: Silicon Graphics, Inc.<br>
> > > srcversion: 0C1B17926BDDA4F121479EE<br>
> > > depends: exportfs<br>
> > > vermagic: 2.6.32-504.23.4.el6.x86_64 SMP mod_unload modversion<br>
> > ><br>
> ><br>
> > No, this isn't the debug version. We need the one from the debug package<br>
> > that was installed (/usr/lib/debug?).<br>
> ><br>
> > Brian<br>
> ><br>
> > > Thanks // Hugo<br>
> > > <br>
> > ><br></span><span class="">
> > > 2015-07-10 2:32 GMT+08:00 Brian Foster <<a href="mailto:bfoster@redhat.com" target="_blank">bfoster@redhat.com</a>>:<br>
> > ><br>
> > > > On Fri, Jul 10, 2015 at 12:40:00AM +0800, Kuo Hugo wrote:<br>
> > > > > Hi Brain,<br>
> > > > ><br>
> > > > > There you go.<br>
> > > > ><br></span>
> > > > > <a href="https://cloud.swiftstack.com/v1/AUTH_hugo/public/vmlinux" rel="noreferrer" target="_blank">https://cloud.swiftstack.com/v1/AUTH_hugo/public/vmlinux</a><br>
> > > > ><br>
> > > ><br>
> > <a href="https://cloud.swiftstack.com/v1/AUTH_hugo/public/System.map-2.6.32-504.23.4.el6.x86_64" rel="noreferrer" target="_blank">https://cloud.swiftstack.com/v1/AUTH_hugo/public/System.map-2.6.32-504.23.4.el6.x86_64</a><span class=""><br>
> > > > ><br>
> > > > > $ md5sum vmlinux<br>
> > > > > 82aaa694a174c0a29e78c05e73adf5d8 vmlinux<br>
> > > > ><br>
> > > > > Yes, I can read it with this vmlinux image. Put all files<br>
> > > > > (vmcore,vmlinux,System.map) in a folder and run $crash vmlinux vmcore<br>
> > > > ><br>
> > > ><br>
> > > > Thanks, I can actually load that up now. Note that we'll probably need<br>
> > > > the modules and whatnot (xfs.ko) also to be able to look at any XFS<br>
> > > > bits. It might be easiest to just tar up and compress whatever<br>
> > directory<br>
> > > > structure has the debug-enabled vmlinux and all the kernel modules.<br>
> > > > Thanks.<br>
> > > ><br>
> > > > Brian<br>
> > > ><br>
> > > > > Hugo<br>
> > > > > <br>
> > > > ><br></span><span class="">
> > > > > 2015-07-09 23:18 GMT+08:00 Brian Foster <<a href="mailto:bfoster@redhat.com" target="_blank">bfoster@redhat.com</a>>:<br>
> > > > ><br>
> > > > > > On Thu, Jul 09, 2015 at 09:20:00PM +0800, Kuo Hugo wrote:<br>
> > > > > > > Hi Brian,<br>
> > > > > > ><br>
> > > > > > > *Operating System Version:*<br>
> > > > > > > Linux-2.6.32-504.23.4.el6.x86_64-x86_64-with-centos-6.6-Final<br>
> > > > > > ><br>
> > > > > > > *NODE 1*<br>
> > > > > > ><br>
> > > > > > > <a href="https://cloud.swiftstack.com/v1/AUTH_burton/brtnswift/vmcore" rel="noreferrer" target="_blank">https://cloud.swiftstack.com/v1/AUTH_burton/brtnswift/vmcore</a><br>
> > > > > > ><br></span>
> > > > <a href="https://cloud.swiftstack.com/v1/AUTH_burton/brtnswift/vmcore-dmesg.txt" rel="noreferrer" target="_blank">https://cloud.swiftstack.com/v1/AUTH_burton/brtnswift/vmcore-dmesg.txt</a><br>
> > > > > > ><br>
> > > > > > ><br>
> > > > > > > *NODE 2*<br>
> > > > > > ><br>
> > > > > > ><br>
> > <a href="https://cloud.swiftstack.com/v1/AUTH_burton/brtnswift/vmcore_r2obj02" rel="noreferrer" target="_blank">https://cloud.swiftstack.com/v1/AUTH_burton/brtnswift/vmcore_r2obj02</a><br>
> > > > > > ><br>
> > > > > ><br>
> > > ><br>
> > <a href="https://cloud.swiftstack.com/v1/AUTH_burton/brtnswift/vmcore-dmesg_r2obj02.txt" rel="noreferrer" target="_blank">https://cloud.swiftstack.com/v1/AUTH_burton/brtnswift/vmcore-dmesg_r2obj02.txt</a><span class=""><br>
> > > > > > ><br>
> > > > > > ><br>
> > > > > > > Any thoughts would be appreciate<br>
> > > > > > ><br>
> > > > > ><br>
> > > > > > I'm not able to fire up crash with these core files and the kernel<br>
> > > > debug<br>
> > > > > > info from the following centos kernel debuginfo package:<br>
> > > > > ><br>
> > > > > > kernel-debuginfo-2.6.32-504.23.4.el6.centos.plus.x86_64.rpm<br>
> > > > > ><br>
> > > > > > It complains about a version mismatch between the vmlinux and core<br>
> > > > file.<br>
> > > > > > I'm no crash expert... are you sure the cores above correspond to<br>
> > this<br>
> > > > > > kernel? Does crash load up for you on said box if you run something<br>
> > > > like<br>
> > > > > > the following?<br>
> > > > > ><br>
> > > > > > crash /usr/lib/debug/lib/modules/.../vmlinux vmcore<br>
> > > > > ><br>
> > > > > > Note that you might need to install the above kernel-debuginfo<br>
> > package<br>
> > > > > > to get the debug (vmlinux) file. If so, could you also upload that<br>
> > > > > > debuginfo rpm somewhere?<br>
> > > > > ><br>
> > > > > > Brian<br>
> > > > > ><br>
> > > > > > > Thanks // Hugo<br>
> > > > > > ><br>
> > > > > > ><br></span><div><div class="h5">
> > > > > > > 2015-07-09 20:51 GMT+08:00 Brian Foster <<a href="mailto:bfoster@redhat.com" target="_blank">bfoster@redhat.com</a>>:<br>
> > > > > > ><br>
> > > > > > > > On Thu, Jul 09, 2015 at 06:57:55PM +0800, Kuo Hugo wrote:<br>
> > > > > > > > > Hi Folks,<br>
> > > > > > > > ><br>
> > > > > > > > > As the results of 32 disks with xfs_repair -n seems no any<br>
> > error<br>
> > > > > > shows<br>
> > > > > > > > up.<br>
> > > > > > > > > We currently tried to deploy CentOS 6.6 for testing. (The<br>
> > > > previous<br>
> > > > > > kernel<br>
> > > > > > > > > panic was came from Ubuntu).<br>
> > > > > > > > > The CentOS nodes encountered kernel panic with same daemon<br>
> > but<br>
> > > > the<br>
> > > > > > > > problem<br>
> > > > > > > > > may a bit differ.<br>
> > > > > > > > ><br>
> > > > > > > > > - It was broken on xfs_dir2_sf_get_parent_ino+0xa/0x20 in<br>
> > > > Ubuntu.<br>
> > > > > > > > > - Here’s the log in CentOS. It’s broken on<br>
> > > > > > > > > xfs_dir2_sf_getdents+0x2a0/0x3a0<br>
> > > > > > > > ><br>
> > > > > > > ><br>
> > > > > > > > I'd venture to guess it's the same behavior here. The previous<br>
> > > > kernel<br>
> > > > > > > > had a callback for the parent inode number that was called via<br>
> > > > > > > > xfs_dir2_sf_getdents(). Taking a look at a 6.6 kernel, it has a<br>
> > > > static<br>
> > > > > > > > inline here instead.<br>
> > > > > > > ><br>
> > > > > > > > > <1>BUG: unable to handle kernel NULL pointer dereference at<br>
> > > > > > > > 0000000000000001<br>
> > > > > > > > > <1>IP: [<ffffffffa0362d60>] xfs_dir2_sf_getdents+0x2a0/0x3a0<br>
> > > > [xfs]<br>
> > > > > > > > > <4>PGD 1072327067 PUD 1072328067 PMD 0<br>
> > > > > > > > > <4>Oops: 0000 [#1] SMP<br>
> > > > > > > > > <4>last sysfs file:<br>
> > > > > > > > ><br>
> > > > > > > ><br>
> > > > > ><br>
> > > ><br>
> > /sys/devices/pci0000:80/0000:80:03.2/0000:83:00.0/host10/port-10:1/expander-10:1/port-10:1:16/end_device-10:1:16/target10:0:25/10:0:25:0/block/sdz/queue/rotational<br>
> > > > > > > > > <4>CPU 17<br>
> > > > > > > > > <4>Modules linked in: xt_conntrack tun xfs exportfs<br>
> > > > iptable_filter<br>
> > > > > > > > > ipt_REDIRECT iptable_nat nf_nat nf_conntrack_ipv4<br>
> > nf_conntrack<br>
> > > > > > > > > nf_defrag_ipv4 ip_tables ip_vs ipv6 libcrc32c iTCO_wdt<br>
> > > > > > > > > iTCO_vendor_support ses enclosure igb i2c_algo_bit sb_edac<br>
> > > > edac_core<br>
> > > > > > > > > i2c_i801 i2c_core sg shpchp lpc_ich mfd_core ixgbe dca ptp<br>
> > > > pps_core<br>
> > > > > > > > > mdio power_meter acpi_ipmi ipmi_si ipmi_msghandler ext4 jbd2<br>
> > > > mbcache<br>
> > > > > > > > > sd_mod crc_t10dif mpt3sas scsi_transport_sas raid_class<br>
> > xhci_hcd<br>
> > > > ahci<br>
> > > > > > > > > wmi dm_mirror dm_region_hash dm_log dm_mod [last unloaded:<br>
> > > > > > > > > scsi_wait_scan]<br>
> > > > > > > > > <4><br>
> > > > > > > > > <4>Pid: 4454, comm: swift-object-se Not tainted<br>
> > > > > > > > > 2.6.32-504.23.4.el6.x86_64 #1 Silicon Mechanics Storform<br>
> > > > > > > > > R518.v5P/X10DRi-T4+<br>
> > > > > > > > > <4>RIP: 0010:[<ffffffffa0362d60>] [<ffffffffa0362d60>]<br>
> > > > > > > > > xfs_dir2_sf_getdents+0x2a0/0x3a0 [xfs]<br>
> > > > > > > > > <4>RSP: 0018:ffff880871f6de18 EFLAGS: 00010202<br>
> > > > > > > > > <4>RAX: 0000000000000000 RBX: 0000000000000004 RCX:<br>
> > > > 0000000000000000<br>
> > > > > > > > > <4>RDX: 0000000000000001 RSI: 0000000000000000 RDI:<br>
> > > > 00007faa74006203<br>
> > > > > > > > > <4>RBP: ffff880871f6de68 R08: 000000032eb04bc9 R09:<br>
> > > > 0000000000000004<br>
> > > > > > > > > <4>R10: 0000000000008030 R11: 0000000000000246 R12:<br>
> > > > 0000000000000000<br>
> > > > > > > > > <4>R13: 0000000000000002 R14: ffff88106eff7000 R15:<br>
> > > > ffff8808715b4580<br>
> > > > > > > > > <4>FS: 00007faa85425700(0000) GS:ffff880028360000(0000)<br>
> > > > > > > > knlGS:0000000000000000<br>
> > > > > > > > > <4>CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br>
> > > > > > > > > <4>CR2: 0000000000000001 CR3: 0000001072325000 CR4:<br>
> > > > 00000000001407e0<br>
> > > > > > > > > <4>DR0: 0000000000000000 DR1: 0000000000000000 DR2:<br>
> > > > 0000000000000000<br>
> > > > > > > > > <4>DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:<br>
> > > > 0000000000000400<br>
> > > > > > > > > <4>Process swift-object-se (pid: 4454, threadinfo<br>
> > > > ffff880871f6c000,<br>
> > > > > > > > > task ffff880860f18ab0)<br>
> > > > > > > > > <4>Stack:<br>
> > > > > > > > > <4> ffff880871f6de28 ffffffff811a4bb0 ffff880871f6df38<br>
> > > > > > ffff880874749cc0<br>
> > > > > > > > > <4><d> 0000000100000103 ffff8802381f8c00 ffff880871f6df38<br>
> > > > > > > > ffff8808715b4580<br>
> > > > > > > > > <4><d> 0000000000000082 ffff8802381f8d88 ffff880871f6dec8<br>
> > > > > > > > ffffffffa035ab31<br>
> > > > > > > > > <4>Call Trace:<br>
> > > > > > > > > <4> [<ffffffff811a4bb0>] ? filldir+0x0/0xe0<br>
> > > > > > > > > <4> [<ffffffffa035ab31>] xfs_readdir+0xe1/0x130 [xfs]<br>
> > > > > > > > > <4> [<ffffffff811a4bb0>] ? filldir+0x0/0xe0<br>
> > > > > > > > > <4> [<ffffffffa038fe29>] xfs_file_readdir+0x39/0x50 [xfs]<br>
> > > > > > > > > <4> [<ffffffff811a4e30>] vfs_readdir+0xc0/0xe0<br>
> > > > > > > > > <4> [<ffffffff8119bd86>] ? final_putname+0x26/0x50<br>
> > > > > > > > > <4> [<ffffffff811a4fb9>] sys_getdents+0x89/0xf0<br>
> > > > > > > > > <4> [<ffffffff8100b0f2>] system_call_fastpath+0x16/0x1b<br>
> > > > > > > > > <4>Code: 01 00 00 00 48 c7 c6 38 6b 3a a0 48 8b 7d c0 ff 55<br>
> > b8<br>
> > > > 85 c0<br>
> > > > > > > > > 0f 85 af 00 00 00 49 8b 37 e9 ec fd ff ff 66 0f 1f 84 00 00<br>
> > 00<br>
> > > > 00 00<br>
> > > > > > > > > <41> 80 7c 24 01 00 0f 84 9c 00 00 00 45 0f b6 44 24 03 41<br>
> > 0f b6<br>
> > > > > > > > > <1>RIP [<ffffffffa0362d60>] xfs_dir2_sf_getdents+0x2a0/0x3a0<br>
> > > > [xfs]<br>
> > > > > > > > > <4> RSP <ffff880871f6de18><br>
> > > > > > > > > <4>CR2: 0000000000000001<br>
> > > > > > > > ><br>
> > > > > > > > ...<br>
> > > > > > > > ><br>
> > > > > > > > > I’ve got the vmcore dump from operator. Does vmcore help for<br>
> > > > > > > > > troubleshooting kind issue ?<br>
> > > > > > > > ><br>
> > > > > > > ><br>
> > > > > > > > Hmm, well it couldn't hurt. Is the vmcore based on this 6.6<br>
> > > > kernel? Can<br>
> > > > > > > > you provide the exact kernel version and post the vmcore<br>
> > somewhere?<br>
> > > > > > > ><br>
> > > > > > > > Brian<br>
> > > > > > > ><br>
> > > > > > > > > Thanks // Hugo<br>
> > > > > > > > > <br>
> > > > > > > > ><br></div></div><span class="">
> > > > > > > > > 2015-06-18 22:59 GMT+08:00 Eric Sandeen <<a href="mailto:sandeen@sandeen.net" target="_blank">sandeen@sandeen.net</a><br>
> > >:<br>
> > > > > > > > ><br>
> > > > > > > > > > On 6/18/15 9:29 AM, Kuo Hugo wrote:<br>
> > > > > > > > > > >>- Have you tried an 'xfs_repair -n' of the affected<br>
> > > > filesystem?<br>
> > > > > > Note<br>
> > > > > > > > > > that -n will report problems only and prevent any<br>
> > modification<br>
> > > > by<br>
> > > > > > > > repair.<br>
> > > > > > > > > > ><br>
> > > > > > > > > > > *We might to to xfs_repair if we can address which disk<br>
> > > > causes<br>
> > > > > > the<br>
> > > > > > > > > > issue. *<br>
> > > > > > > > > ><br>
> > > > > > > > > > If you do, please save the output, and if it finds<br>
> > anything,<br>
> > > > please<br>
> > > > > > > > > > provide the output in this thread.<br>
> > > > > > > > > ><br>
> > > > > > > > > > Thanks,<br>
> > > > > > > > > > -Eric<br>
> > > > > > > > > ><br>
> > > > > > > ><br>
> > > > > > > > > _______________________________________________<br>
> > > > > > > > > xfs mailing list<br></span>
> > > > > > > > > <a href="mailto:xfs@oss.sgi.com" target="_blank">xfs@oss.sgi.com</a><br>
> > > > > > > > > <a href="http://oss.sgi.com/mailman/listinfo/xfs" rel="noreferrer" target="_blank">http://oss.sgi.com/mailman/listinfo/xfs</a><br>
> > > > > > > ><br>
> > > > > > > ><br>
> > > > > ><br>
> > > ><br>
> ><br>
> > > _______________________________________________<br>
> > > xfs mailing list<span class=""><br>
> > > <a href="mailto:xfs@oss.sgi.com" target="_blank">xfs@oss.sgi.com</a><br>
> > > <a href="http://oss.sgi.com/mailman/listinfo/xfs" rel="noreferrer" target="_blank">http://oss.sgi.com/mailman/listinfo/xfs</a><br>
> ><br>
> ><br>
</span></div></div></blockquote></div><br></div>
</blockquote></div><br></div>