can xfs_repair guarantee a complete clean filesystem?

can xfs_repair guarantee a complete clean filesystem?

[hank peng]

When using xfs_repair, I want my XFS filesystem complete clean and
continue to work even if some files lost. Becase we use XFS in low-end
NAS box, customers want a tool to repair the filesystem when it has
problem and they allow some files be lost and don't want the whole
system to stop.
So, I wonder if xfs_repair or some other tools can satisfy this funciton?

-- 
The simplest is not all best but the best is surely the simplest!

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: can xfs_repair guarantee a complete clean filesystem?

[Eric Sandeen]

hank peng wrote:
> When using xfs_repair, I want my XFS filesystem complete clean and
> continue to work even if some files lost. Becase we use XFS in low-end
> NAS box, customers want a tool to repair the filesystem when it has
> problem and they allow some files be lost and don't want the whole
> system to stop.
> So, I wonder if xfs_repair or some other tools can satisfy this funciton?
> 

Yes, that is exactly its purpose (any potential bugs notwithstanding...)

-Eric

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: can xfs_repair guarantee a complete clean filesystem?

[hank peng]

2009/12/1 Eric Sandeen <sandeen@sandeen.net>:
> hank peng wrote:
>> When using xfs_repair, I want my XFS filesystem complete clean and
>> continue to work even if some files lost. Becase we use XFS in low-end
>> NAS box, customers want a tool to repair the filesystem when it has
>> problem and they allow some files be lost and don't want the whole
>> system to stop.
>> So, I wonder if xfs_repair or some other tools can satisfy this funciton?
>>
>
> Yes, that is exactly its purpose (any potential bugs notwithstanding...)
>
Thanks for your reply.
Is there some points I should notice about when using xfs_repair? I
used to encounter some cases in which xfs_repair complete successfully
but some errors like "Corrupt in memory detected" occured when the
filesytem is put into online for short time.
Should I reboot the machine and use xfs_repair before the damaged
filesystem is used, or some other options I should use?
In addition, I googled some information and found that some people say
xfs_check should be used before xfs_repair, is it right?

> -Eric
>



-- 
The simplest is not all best but the best is surely the simplest!

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: can xfs_repair guarantee a complete clean filesystem?

[Eric Sandeen]

hank peng wrote:
> 2009/12/1 Eric Sandeen <sandeen@sandeen.net>:
>> hank peng wrote:
>>> When using xfs_repair, I want my XFS filesystem complete clean and
>>> continue to work even if some files lost. Becase we use XFS in low-end
>>> NAS box, customers want a tool to repair the filesystem when it has
>>> problem and they allow some files be lost and don't want the whole
>>> system to stop.
>>> So, I wonder if xfs_repair or some other tools can satisfy this funciton?
>>>
>> Yes, that is exactly its purpose (any potential bugs notwithstanding...)
>>
> Thanks for your reply.
> Is there some points I should notice about when using xfs_repair? I
> used to encounter some cases in which xfs_repair complete successfully
> but some errors like "Corrupt in memory detected" occured when the
> filesytem is put into online for short time.

It's possible that you encountered a bug (in xfs or elsewhere), or
bad hardware...

> Should I reboot the machine and use xfs_repair before the damaged
> filesystem is used, or some other options I should use?

Just unmount the filesystem, run repair, and remount.

> In addition, I googled some information and found that some people say
> xfs_check should be used before xfs_repair, is it right?

There's no need; xfs_check doesn't scale very well, and xfs_repair -n will do
a check-only run if that's what you want.

xfs_check checks a little more than xfs_repair, but xfs_repair simply
rebuilds those things it doesn't check in any case.

-Eric

>> -Eric
>>
> 
> 
> 

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: can xfs_repair guarantee a complete clean filesystem?

[hank peng]

2009/12/1 Eric Sandeen <sandeen@sandeen.net>:
> hank peng wrote:
>> 2009/12/1 Eric Sandeen <sandeen@sandeen.net>:
>>> hank peng wrote:
>>>> When using xfs_repair, I want my XFS filesystem complete clean and
>>>> continue to work even if some files lost. Becase we use XFS in low-end
>>>> NAS box, customers want a tool to repair the filesystem when it has
>>>> problem and they allow some files be lost and don't want the whole
>>>> system to stop.
>>>> So, I wonder if xfs_repair or some other tools can satisfy this funciton?
>>>>
>>> Yes, that is exactly its purpose (any potential bugs notwithstanding...)
>>>
>> Thanks for your reply.
>> Is there some points I should notice about when using xfs_repair? I
>> used to encounter some cases in which xfs_repair complete successfully
>> but some errors like "Corrupt in memory detected" occured when the
>> filesytem is put into online for short time.
>
> It's possible that you encountered a bug (in xfs or elsewhere), or
> bad hardware...
>
>> Should I reboot the machine and use xfs_repair before the damaged
>> filesystem is used, or some other options I should use?
>
> Just unmount the filesystem, run repair, and remount.
>
>> In addition, I googled some information and found that some people say
>> xfs_check should be used before xfs_repair, is it right?
>
> There's no need; xfs_check doesn't scale very well, and xfs_repair -n will do
> a check-only run if that's what you want.
>
> xfs_check checks a little more than xfs_repair, but xfs_repair simply
> rebuilds those things it doesn't check in any case.
>
> -Eric
>
Today, I encountered a problem:
I use "xfs_repair -L “ on a damaged filesystem and a lot of messages
output which include "moving disconnected inodes to lost+found ...".
Then I can remount the filesystem successfully and decided to remove
those files in lost+found directory, but it printed the following
message:
root@1234dahua:/mnt/Pool_md1/ss1/lost+found# rm -rf *
rm: cannot stat '710': Structure needs cleaning
rm: cannot stat '728': Structure needs cleaning
rm: cannot stat '729': Structure needs cleaning
rm: cannot stat '730': Structure needs cleaning
rm: cannot stat '731': Structure needs cleaning
rm: cannot stat '732': Structure needs cleaning
rm: cannot stat '733': Structure needs cleaning
rm: cannot stat '734': Structure needs cleaning
rm: cannot stat '735': Structure needs cleaning

Other directories and files seems normal to access, is it not allowed
to delete files in lost+found directory after repair, then what should
I do?

>>> -Eric
>>>
>>
>>
>>
>
>



-- 
The simplest is not all best but the best is surely the simplest!

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: can xfs_repair guarantee a complete clean filesystem?

[Eric Sandeen]

hank peng wrote:

> Today, I encountered a problem:
> I use "xfs_repair -L “ on a damaged filesystem and a lot of messages

why did you use -L, did it fail to mount & replay the log properly?

> output which include "moving disconnected inodes to lost+found ...".
> Then I can remount the filesystem successfully and decided to remove
> those files in lost+found directory, but it printed the following
> message:
> root@1234dahua:/mnt/Pool_md1/ss1/lost+found# rm -rf *
> rm: cannot stat '710': Structure needs cleaning
> rm: cannot stat '728': Structure needs cleaning
> rm: cannot stat '729': Structure needs cleaning
> rm: cannot stat '730': Structure needs cleaning
> rm: cannot stat '731': Structure needs cleaning
> rm: cannot stat '732': Structure needs cleaning
> rm: cannot stat '733': Structure needs cleaning
> rm: cannot stat '734': Structure needs cleaning
> rm: cannot stat '735': Structure needs cleaning

Look at dmesg to see what's gone wrong....

> Other directories and files seems normal to access, is it not allowed
> to delete files in lost+found directory after repair, then what should
> I do?

This is indicative of a bug or IO error that caused xfs to shut down.

You haven't mentioned which kernel version, architecture, or
version of xfsprogs you're using yet ... that may offer some clues.

I'm guessing an older kernel and userspace on arm? :)

-Eric

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: can xfs_repair guarantee a complete clean filesystem?

[hank peng]

2009/12/1 Eric Sandeen <sandeen@sandeen.net>:
> hank peng wrote:
>
>> Today, I encountered a problem:
>> I use "xfs_repair -L “ on a damaged filesystem and a lot of messages
>
> why did you use -L, did it fail to mount & replay the log properly?
>
umount, mount, umount and then xfs_repair failed, so I have to use -L.

>> output which include "moving disconnected inodes to lost+found ...".
>> Then I can remount the filesystem successfully and decided to remove
>> those files in lost+found directory, but it printed the following
>> message:
>> root@1234dahua:/mnt/Pool_md1/ss1/lost+found# rm -rf *
>> rm: cannot stat '710': Structure needs cleaning
>> rm: cannot stat '728': Structure needs cleaning
>> rm: cannot stat '729': Structure needs cleaning
>> rm: cannot stat '730': Structure needs cleaning
>> rm: cannot stat '731': Structure needs cleaning
>> rm: cannot stat '732': Structure needs cleaning
>> rm: cannot stat '733': Structure needs cleaning
>> rm: cannot stat '734': Structure needs cleaning
>> rm: cannot stat '735': Structure needs cleaning
>
> Look at dmesg to see what's gone wrong....
>

>> Other directories and files seems normal to access, is it not allowed
>> to delete files in lost+found directory after repair, then what should
>> I do?
>
> This is indicative of a bug or IO error that caused xfs to shut down.
>
> You haven't mentioned which kernel version, architecture, or
> version of xfsprogs you're using yet ... that may offer some clues.
>

> I'm guessing an older kernel and userspace on arm? :)
>
kernel version is 2.6.23, xfsprogs is 2.9.7, CPU is MPC8548, powerpc arch.
I am at home now, Maybe I can provide some detailed information tomorrow.

> -Eric
>



-- 
The simplest is not all best but the best is surely the simplest!

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: can xfs_repair guarantee a complete clean filesystem?

[Eric Sandeen]

hank peng wrote:
> 2009/12/1 Eric Sandeen <sandeen@sandeen.net>:
>> hank peng wrote:
>>
>>> Today, I encountered a problem:
>>> I use "xfs_repair -L “ on a damaged filesystem and a lot of messages
>> why did you use -L, did it fail to mount & replay the log properly?
>>
> umount, mount, umount and then xfs_repair failed, so I have to use -L.

Failed how?  that's a bug.  (or, -L did nothing anyway because the log
wasn't dirty after the clean unmount)

>>> output which include "moving disconnected inodes to lost+found ...".
>>> Then I can remount the filesystem successfully and decided to remove
>>> those files in lost+found directory, but it printed the following
>>> message:
>>> root@1234dahua:/mnt/Pool_md1/ss1/lost+found# rm -rf *
>>> rm: cannot stat '710': Structure needs cleaning
>>> rm: cannot stat '728': Structure needs cleaning
>>> rm: cannot stat '729': Structure needs cleaning
>>> rm: cannot stat '730': Structure needs cleaning
>>> rm: cannot stat '731': Structure needs cleaning
>>> rm: cannot stat '732': Structure needs cleaning
>>> rm: cannot stat '733': Structure needs cleaning
>>> rm: cannot stat '734': Structure needs cleaning
>>> rm: cannot stat '735': Structure needs cleaning
>> Look at dmesg to see what's gone wrong....
>>
> 
>>> Other directories and files seems normal to access, is it not allowed
>>> to delete files in lost+found directory after repair, then what should
>>> I do?
>> This is indicative of a bug or IO error that caused xfs to shut down.
>>
>> You haven't mentioned which kernel version, architecture, or
>> version of xfsprogs you're using yet ... that may offer some clues.
>>
> 
>> I'm guessing an older kernel and userspace on arm? :)
>>
> kernel version is 2.6.23, xfsprogs is 2.9.7, CPU is MPC8548, powerpc arch.
> I am at home now, Maybe I can provide some detailed information tomorrow.

If there's any possibility to test newer kernel & userspace, that'd 
be great.  Many bugs have been fixed since those versions.

-Eric

>> -Eric
>>
> 
> 
> 

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: can xfs_repair guarantee a complete clean filesystem?

[hank peng]

2009/12/1 Eric Sandeen <sandeen@sandeen.net>:
> hank peng wrote:
>> 2009/12/1 Eric Sandeen <sandeen@sandeen.net>:
>>> hank peng wrote:
>>>
>>>> Today, I encountered a problem:
>>>> I use "xfs_repair -L “ on a damaged filesystem and a lot of messages
>>> why did you use -L, did it fail to mount & replay the log properly?
>>>
>> umount, mount, umount and then xfs_repair failed, so I have to use -L.
>
> Failed how?  that's a bug.  (or, -L did nothing anyway because the log
> wasn't dirty after the clean unmount)
>
>>>> output which include "moving disconnected inodes to lost+found ...".
>>>> Then I can remount the filesystem successfully and decided to remove
>>>> those files in lost+found directory, but it printed the following
>>>> message:
>>>> root@1234dahua:/mnt/Pool_md1/ss1/lost+found# rm -rf *
>>>> rm: cannot stat '710': Structure needs cleaning
>>>> rm: cannot stat '728': Structure needs cleaning
>>>> rm: cannot stat '729': Structure needs cleaning
>>>> rm: cannot stat '730': Structure needs cleaning
>>>> rm: cannot stat '731': Structure needs cleaning
>>>> rm: cannot stat '732': Structure needs cleaning
>>>> rm: cannot stat '733': Structure needs cleaning
>>>> rm: cannot stat '734': Structure needs cleaning
>>>> rm: cannot stat '735': Structure needs cleaning
>>> Look at dmesg to see what's gone wrong....
>>>
>>
>>>> Other directories and files seems normal to access, is it not allowed
>>>> to delete files in lost+found directory after repair, then what should
>>>> I do?
>>> This is indicative of a bug or IO error that caused xfs to shut down.
>>>
>>> You haven't mentioned which kernel version, architecture, or
>>> version of xfsprogs you're using yet ... that may offer some clues.
>>>
>>
>>> I'm guessing an older kernel and userspace on arm? :)
>>>
>> kernel version is 2.6.23, xfsprogs is 2.9.7, CPU is MPC8548, powerpc arch.
>> I am at home now, Maybe I can provide some detailed information tomorrow.
>
> If there's any possibility to test newer kernel & userspace, that'd
> be great.  Many bugs have been fixed since those versions.
>
We did have plan to upgrade kernel to latest 2.6.31.
BTW, Is there some place where I can check those fixed bug list across versions?
> -Eric
>
>>> -Eric
>>>
>>
>>
>>
>
>



-- 
The simplest is not all best but the best is surely the simplest!

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: can xfs_repair guarantee a complete clean filesystem?

[Eric Sandeen]

hank peng wrote:
> 2009/12/1 Eric Sandeen <sandeen@sandeen.net>:

...

>>> kernel version is 2.6.23, xfsprogs is 2.9.7, CPU is MPC8548, powerpc arch.
>>> I am at home now, Maybe I can provide some detailed information tomorrow.
>> If there's any possibility to test newer kernel & userspace, that'd
>> be great.  Many bugs have been fixed since those versions.
>>
> We did have plan to upgrade kernel to latest 2.6.31.

Well, I'm just suggesting testing it for now, not necessarily
upgrading your product.  Would just be good to know if the bug you
are seeing persists upstream on ppc.

> BTW, Is there some place where I can check those fixed bug list across versions?

You can look at the changelogs on kernel.org, for instance:

http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.32

Or with git, git log --pretty-oneline fs/xfs

There isn't a great bug <-> commit <-> kernelversion mapping, I guess.

-Eric

>> -Eric

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: can xfs_repair guarantee a complete clean filesystem?

[hank peng]

2009/12/2 Eric Sandeen <sandeen@sandeen.net>:
> hank peng wrote:
>> 2009/12/1 Eric Sandeen <sandeen@sandeen.net>:
>
> ...
>
>>>> kernel version is 2.6.23, xfsprogs is 2.9.7, CPU is MPC8548, powerpc arch.
>>>> I am at home now, Maybe I can provide some detailed information tomorrow.
>>> If there's any possibility to test newer kernel & userspace, that'd
>>> be great.  Many bugs have been fixed since those versions.
>>>
>> We did have plan to upgrade kernel to latest 2.6.31.
>
> Well, I'm just suggesting testing it for now, not necessarily
> upgrading your product.  Would just be good to know if the bug you
> are seeing persists upstream on ppc.
>
Sad, our test engineer had deleted that damaged filesystem, I have to
reproduce test again and wait for it to happen.
I will replace newer kernel to test immediately when this problem
occure again and let you know ASAP.

>> BTW, Is there some place where I can check those fixed bug list across versions?
>
> You can look at the changelogs on kernel.org, for instance:
>
> http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.32
>
> Or with git, git log --pretty-oneline fs/xfs
>
> There isn't a great bug <-> commit <-> kernelversion mapping, I guess.
>
> -Eric
>
>>> -Eric
>
>



-- 
The simplest is not all best but the best is surely the simplest!

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: can xfs_repair guarantee a complete clean filesystem?

[hank peng]

Hi, Eric:
I think I have reproduced the problem.

# uname -a
Linux 1234dahua 2.6.23 #747 Mon Nov 16 10:52:58 CST 2009 ppc unknown
#mdadm -C /dev/md1 -l5 -n3 /dev/sd{h,c,b}
# cat /proc/mdstat
Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5]
[raid4] [multipath]
md1 : active raid5 sdb[3] sdc[1] sdh[0]
      976772992 blocks level 5, 64k chunk, algorithm 2 [3/2] [UU_]
      [==>..................]  recovery = 13.0% (63884032/488386496)
finish=103.8min speed=68124K/sec

unused devices: <none>
#pvcreate /dev/md1
#vgcreate Pool_md1 /dev/md1
#lvcreate -L 931G -n testlv Pool_md1
#lvdisplay
# lvdisplay
  --- Logical volume ---
  LV Name                /dev/Pool_md1/testlv
  VG Name                Pool_md1
  LV UUID                jWTgk5-Q6tf-jSEU-m9VZ-K2Kb-1oRW-R7oP94
  LV Write Access        read/write
  LV Status              available
  # open                 1
  LV Size                931.00 GB
  Current LE             238336
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           253:0

#mkfs.xfs -f -ssize=4k /dev/Pool_md1/testlv
#mount /dev/Pool_md1/testlv /mnt/Pool_md1/testlv
All is OK and mount the filesystem and began to write files into it
through our application software. For a short while, problem occured.
# cd /mnt/Pool_md1/testlv
cd: error retrieving current directory: getcwd: cannot access parent
directories: Input/output error
#dmesg | tail -n 30
--- rd:3 wd:2
 disk 0, o:1, dev:sdh
 disk 1, o:1, dev:sdc
RAID5 conf printout:
 --- rd:3 wd:2
 disk 0, o:1, dev:sdh
 disk 1, o:1, dev:sdc
 disk 2, o:1, dev:sdb
md: recovery of RAID array md1
md: minimum _guaranteed_  speed: 1000 KB/sec/disk.
md: using maximum available idle IO bandwidth (but not more than
200000 KB/sec) for recovery.
md: using 128k window, over a total of 488386496 blocks.
Filesystem "dm-0": Disabling barriers, not supported by the underlying device
XFS mounting filesystem dm-0
Ending clean XFS mount for filesystem: dm-0
Filesystem "dm-0": XFS internal error xfs_trans_cancel at line 1169 of
file fs/xfs/xfs_trans.c.  Caller 0xc019fbf0
Call Trace:
[e8e6dcb0] [c00091ec] show_stack+0x3c/0x1a0 (unreliable)
[e8e6dce0] [c017559c] xfs_error_report+0x50/0x60
[e8e6dcf0] [c0197058] xfs_trans_cancel+0x124/0x140
[e8e6dd10] [c019fbf0] xfs_create+0x1fc/0x63c
[e8e6dd90] [c01ad690] xfs_vn_mknod+0x1ac/0x20c
[e8e6de40] [c007ded4] vfs_create+0xa8/0xe4
[e8e6de60] [c0081370] open_namei+0x5f0/0x688
[e8e6deb0] [c00729b8] do_filp_open+0x2c/0x6c
[e8e6df20] [c0072a54] do_sys_open+0x5c/0xf8
[e8e6df40] [c0002320] ret_from_syscall+0x0/0x3c
xfs_force_shutdown(dm-0,0x8) called from line 1170 of file
fs/xfs/xfs_trans.c.  Return address = 0xc01b0b74
Filesystem "dm-0": Corruption of in-memory data detected.  Shutting
down filesystem: dm-0
Please umount the filesystem, and rectify the problem(s)

What shoul I do now? use xfs_repair or use newer kernel ? Please let
me know if you need other information.

2009/12/2 Eric Sandeen <sandeen@sandeen.net>:
> hank peng wrote:
>> 2009/12/1 Eric Sandeen <sandeen@sandeen.net>:
>
> ...
>
>>>> kernel version is 2.6.23, xfsprogs is 2.9.7, CPU is MPC8548, powerpc arch.
>>>> I am at home now, Maybe I can provide some detailed information tomorrow.
>>> If there's any possibility to test newer kernel & userspace, that'd
>>> be great.  Many bugs have been fixed since those versions.
>>>
>> We did have plan to upgrade kernel to latest 2.6.31.
>
> Well, I'm just suggesting testing it for now, not necessarily
> upgrading your product.  Would just be good to know if the bug you
> are seeing persists upstream on ppc.
>
>> BTW, Is there some place where I can check those fixed bug list across versions?
>
> You can look at the changelogs on kernel.org, for instance:
>
> http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.32
>
> Or with git, git log --pretty-oneline fs/xfs
>
> There isn't a great bug <-> commit <-> kernelversion mapping, I guess.
>
> -Eric
>
>>> -Eric
>
>



-- 
The simplest is not all best but the best is surely the simplest!

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: can xfs_repair guarantee a complete clean filesystem?

[Eric Sandeen]

hank peng wrote:
> Hi, Eric:
> I think I have reproduced the problem.
> 
> # uname -a
> Linux 1234dahua 2.6.23 #747 Mon Nov 16 10:52:58 CST 2009 ppc unknown
> #mdadm -C /dev/md1 -l5 -n3 /dev/sd{h,c,b}
> # cat /proc/mdstat
> Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5]
> [raid4] [multipath]
> md1 : active raid5 sdb[3] sdc[1] sdh[0]
>       976772992 blocks level 5, 64k chunk, algorithm 2 [3/2] [UU_]
>       [==>..................]  recovery = 13.0% (63884032/488386496)
> finish=103.8min speed=68124K/sec
> 
> unused devices: <none>
> #pvcreate /dev/md1
> #vgcreate Pool_md1 /dev/md1
> #lvcreate -L 931G -n testlv Pool_md1
> #lvdisplay
> # lvdisplay
>   --- Logical volume ---
>   LV Name                /dev/Pool_md1/testlv
>   VG Name                Pool_md1
>   LV UUID                jWTgk5-Q6tf-jSEU-m9VZ-K2Kb-1oRW-R7oP94
>   LV Write Access        read/write
>   LV Status              available
>   # open                 1
>   LV Size                931.00 GB
>   Current LE             238336
>   Segments               1
>   Allocation             inherit
>   Read ahead sectors     auto
>   - currently set to     256
>   Block device           253:0
> 
> #mkfs.xfs -f -ssize=4k /dev/Pool_md1/testlv
> #mount /dev/Pool_md1/testlv /mnt/Pool_md1/testlv
> All is OK and mount the filesystem and began to write files into it
> through our application software. For a short while, problem occured.
> # cd /mnt/Pool_md1/testlv
> cd: error retrieving current directory: getcwd: cannot access parent
> directories: Input/output error
> #dmesg | tail -n 30
> --- rd:3 wd:2
>  disk 0, o:1, dev:sdh
>  disk 1, o:1, dev:sdc
> RAID5 conf printout:
>  --- rd:3 wd:2
>  disk 0, o:1, dev:sdh
>  disk 1, o:1, dev:sdc
>  disk 2, o:1, dev:sdb
> md: recovery of RAID array md1
> md: minimum _guaranteed_  speed: 1000 KB/sec/disk.
> md: using maximum available idle IO bandwidth (but not more than
> 200000 KB/sec) for recovery.
> md: using 128k window, over a total of 488386496 blocks.
> Filesystem "dm-0": Disabling barriers, not supported by the underlying device
> XFS mounting filesystem dm-0
> Ending clean XFS mount for filesystem: dm-0
> Filesystem "dm-0": XFS internal error xfs_trans_cancel at line 1169 of
> file fs/xfs/xfs_trans.c.  Caller 0xc019fbf0
> Call Trace:
> [e8e6dcb0] [c00091ec] show_stack+0x3c/0x1a0 (unreliable)
> [e8e6dce0] [c017559c] xfs_error_report+0x50/0x60
> [e8e6dcf0] [c0197058] xfs_trans_cancel+0x124/0x140
> [e8e6dd10] [c019fbf0] xfs_create+0x1fc/0x63c
> [e8e6dd90] [c01ad690] xfs_vn_mknod+0x1ac/0x20c
> [e8e6de40] [c007ded4] vfs_create+0xa8/0xe4
> [e8e6de60] [c0081370] open_namei+0x5f0/0x688
> [e8e6deb0] [c00729b8] do_filp_open+0x2c/0x6c
> [e8e6df20] [c0072a54] do_sys_open+0x5c/0xf8
> [e8e6df40] [c0002320] ret_from_syscall+0x0/0x3c
> xfs_force_shutdown(dm-0,0x8) called from line 1170 of file
> fs/xfs/xfs_trans.c.  Return address = 0xc01b0b74
> Filesystem "dm-0": Corruption of in-memory data detected.  Shutting
> down filesystem: dm-0
> Please umount the filesystem, and rectify the problem(s)
> 
> What shoul I do now? use xfs_repair or use newer kernel ? Please let
> me know if you need other information.

Test upstream; if it passes, test kernels in between to see if you can find
out when it got fixed, and maybe you can backport it.

If it fails upstream, we have an unfixed bug and we'll try to help you find it.

-Eric

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs