XFS: bad clientid on recovery on MIPS (VIPT cache)

XFS: bad clientid on recovery on MIPS (VIPT cache)

[Ajeet Yadav]

[-- Attachment #1.1: Type: text/plain, Size: 1652 bytes --]

Dear member,
If I remove USB flash storage from PC/ARM/MIPS target (i.e
without umount) while copying file to XFS partition and connect it to MIPS
target I always get
XFS: xlog_recover_process_data: bad clientid
XFS: log mount/recovery failed: error 5
XFS: log mount failed
This problem does not occur, if I connect the same USB flash to PC/ARM
target.
I have tested this on 2.6.30 - 2.6.34 (It everywhere when concerend with
MIPS)

I had two workaround to avoid this problem on MIPS, but I wish to know the
exact reason of this problme on MIPS.
I am really tired and giving up, so finally thought of taking your help,
your guidence can help me.

1. __flush_cache_all() at the begining of each iteration of while loop in
function xlog_recover_process_data().

     while ((dp < lp) && num_logops) {
+       __flush_cache_all() ;
         ASSERT(dp + sizeof(xlog_op_header_t) <= lp);
         ohead = (xlog_op_header_t *)dp;
         dp += sizeof(xlog_op_header_t);
         if (ohead->oh_clientid != XFS_TRANSACTION &&
             ohead->oh_clientid != XFS_LOG) {
             xlog_warn(
             "XFS: xlog_recover_process_data: bad clientid")

OR

2. Provide new buffer in each call to xlog_bread in function
xlog_do_recovery_pass().

          if (error)
              goto bread_err2;
          /* blocks in data section */
          bblks = (int)BTOBB(be32_to_cpu(rhead->h_len));
+        xlog_put_bp(dbp);
+        dbp = xlog_get_bp(log, BTOBB(h_size));
          error = xlog_bread(log, blk_no + hblks, bblks, dbp,
                                     &offset);
          if (error)
              goto bread_err2;

WIth Regards
Ajeet Yadav

[-- Attachment #1.2: Type: text/html, Size: 2067 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]

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

XFS: bad clientid on recovery on MIPS (VIPT cache)

[Ajeet Yadav]

[-- Attachment #1.1: Type: text/plain, Size: 1653 bytes --]

 Dear member,
If I remove USB flash storage from PC/ARM/MIPS target (i.e
without umount) while copying file to XFS partition and connect it to MIPS
target I always get
XFS: xlog_recover_process_data: bad clientid
XFS: log mount/recovery failed: error 5
XFS: log mount failed
This problem does not occur, if I connect the same USB flash to PC/ARM
target.
I have tested this on 2.6.30 - 2.6.34 (It everywhere when concerend with
MIPS)

I had two workaround to avoid this problem on MIPS, but I wish to know the
exact reason of this problme on MIPS.
I am really tired and giving up, so finally thought of taking your help,
your guidence can help me.

1. __flush_cache_all() at the begining of each iteration of while loop in
function xlog_recover_process_data().

     while ((dp < lp) && num_logops) {
+       __flush_cache_all() ;
         ASSERT(dp + sizeof(xlog_op_header_t) <= lp);
         ohead = (xlog_op_header_t *)dp;
         dp += sizeof(xlog_op_header_t);
         if (ohead->oh_clientid != XFS_TRANSACTION &&
             ohead->oh_clientid != XFS_LOG) {
             xlog_warn(
             "XFS: xlog_recover_process_data: bad clientid")

OR

2. Provide new buffer in each call to xlog_bread in function
xlog_do_recovery_pass().

          if (error)
              goto bread_err2;
          /* blocks in data section */
          bblks = (int)BTOBB(be32_to_cpu(rhead->h_len));
+        xlog_put_bp(dbp);
+        dbp = xlog_get_bp(log, BTOBB(h_size));
          error = xlog_bread(log, blk_no + hblks, bblks, dbp,
                                     &offset);
          if (error)
              goto bread_err2;

WIth Regards
Ajeet Yadav

[-- Attachment #1.2: Type: text/html, Size: 2133 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]

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

Re: XFS: bad clientid on recovery on MIPS (VIPT cache)

[Christoph Hellwig]

On Thu, Oct 21, 2010 at 05:41:43PM +0530, Ajeet Yadav wrote:
> Dear member,
> If I remove USB flash storage from PC/ARM/MIPS target (i.e
> without umount) while copying file to XFS partition and connect it to MIPS
> target I always get
> XFS: xlog_recover_process_data: bad clientid
> XFS: log mount/recovery failed: error 5
> XFS: log mount failed
> This problem does not occur, if I connect the same USB flash to PC/ARM
> target.
> I have tested this on 2.6.30 - 2.6.34 (It everywhere when concerend with
> MIPS)

Since Linux 2.6.34 Linux uses the flush_kernel_vmap_range/
invalidate_kernel_vmap_range APIs to make I/O to vmapped
areas work on systems with virtually indexed caches.

Unfortunately only arm, parisc and sh actually implement these so far.
You'll need to implement an implementation of these APIs for your cache
architecture to make XFS work on MIPS with virtually indexed caches.

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

Re: XFS: bad clientid on recovery on MIPS (VIPT cache)

[Ajeet Yadav]

[-- Attachment #1.1: Type: text/plain, Size: 1318 bytes --]

Thanks for response,

Linux kernel I am using is 2.6.30, where as XFS I have ported until 2.6.34
on given kernel.
Do you think I need the mentioned API
flush_kernel_vmap_range/invalidate_kernel_vmap_range in 2.6.30.9 as well.I
will be grateful if you can provide me sample code for the above API.



On Thu, Oct 21, 2010 at 6:22 PM, Christoph Hellwig <hch@infradead.org>wrote:

> On Thu, Oct 21, 2010 at 05:41:43PM +0530, Ajeet Yadav wrote:
> > Dear member,
> > If I remove USB flash storage from PC/ARM/MIPS target (i.e
> > without umount) while copying file to XFS partition and connect it to
> MIPS
> > target I always get
> > XFS: xlog_recover_process_data: bad clientid
> > XFS: log mount/recovery failed: error 5
> > XFS: log mount failed
> > This problem does not occur, if I connect the same USB flash to PC/ARM
> > target.
> > I have tested this on 2.6.30 - 2.6.34 (It everywhere when concerend with
> > MIPS)
>
> Since Linux 2.6.34 Linux uses the flush_kernel_vmap_range/
> invalidate_kernel_vmap_range APIs to make I/O to vmapped
> areas work on systems with virtually indexed caches.
>
> Unfortunately only arm, parisc and sh actually implement these so far.
> You'll need to implement an implementation of these APIs for your cache
> architecture to make XFS work on MIPS with virtually indexed caches.
>

[-- Attachment #1.2: Type: text/html, Size: 1713 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]

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

Re: XFS: bad clientid on recovery on MIPS (VIPT cache)

[Ajeet Yadav]

[-- Attachment #1.1: Type: text/plain, Size: 2409 bytes --]

Hello,
I wish to know, why the problem of bad clientid does not come, if we safely
umount the USB storage device.
Also if anyone can help where XFS uses these
flush_kernel_vmap_range/invalidate_kernel_vmap_range.

With what ever understanding I have developed about log recovery that buffer
"dbp" is updated with new value in xlog_bread(), but the cache hold buffer
lines of last iteration, I think if we can can dpd pages uncachable than it
may solve this problem, pls comment if I am wrong.

dbp = xlog_get_bp(log, BTOBB(h_size)); --------> In function
xlog_do_recovery_pass()

for (blk_no = tail_blk; blk_no < head_blk; ) {
.
    error = xlog_bread(log, blk_no + hblks, bblks, dbp,
                               &offset);
    if (error)
            goto bread_err2;
    xlog_unpack_data(rhead, offset, log);
    if ((error = xlog_recover_process_data(log,
                   rhash, rhead, offset, pass)))
        goto bread_err2;
   blk_no += bblks + hblks;
}



On Thu, Oct 21, 2010 at 6:57 PM, Ajeet Yadav <ajeet.yadav.77@gmail.com>wrote:

> Thanks for response,
>
> Linux kernel I am using is 2.6.30, where as XFS I have ported until 2.6.34
> on given kernel.
> Do you think I need the mentioned API
> flush_kernel_vmap_range/invalidate_kernel_vmap_range in 2.6.30.9 as well.I
> will be grateful if you can provide me sample code for the above API.
>
>
>
> On Thu, Oct 21, 2010 at 6:22 PM, Christoph Hellwig <hch@infradead.org>wrote:
>
>> On Thu, Oct 21, 2010 at 05:41:43PM +0530, Ajeet Yadav wrote:
>> > Dear member,
>> > If I remove USB flash storage from PC/ARM/MIPS target (i.e
>> > without umount) while copying file to XFS partition and connect it to
>> MIPS
>> > target I always get
>> > XFS: xlog_recover_process_data: bad clientid
>> > XFS: log mount/recovery failed: error 5
>> > XFS: log mount failed
>> > This problem does not occur, if I connect the same USB flash to PC/ARM
>> > target.
>> > I have tested this on 2.6.30 - 2.6.34 (It everywhere when concerend with
>> > MIPS)
>>
>> Since Linux 2.6.34 Linux uses the flush_kernel_vmap_range/
>> invalidate_kernel_vmap_range APIs to make I/O to vmapped
>> areas work on systems with virtually indexed caches.
>>
>> Unfortunately only arm, parisc and sh actually implement these so far.
>> You'll need to implement an implementation of these APIs for your cache
>> architecture to make XFS work on MIPS with virtually indexed caches.
>>
>
>

[-- Attachment #1.2: Type: text/html, Size: 3291 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]

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

Re: XFS: bad clientid on recovery on MIPS (VIPT cache)

[Christoph Hellwig]

On Fri, Oct 22, 2010 at 10:55:44AM +0530, Ajeet Yadav wrote:
> Hello,
> I wish to know, why the problem of bad clientid does not come, if we safely
> umount the USB storage device.

Because there the log is only recovered on an unclean umount.

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

Re: XFS: bad clientid on recovery on MIPS (VIPT cache)

[Ajeet Yadav]

[-- Attachment #1.1: Type: text/plain, Size: 345 bytes --]

Ok, I will implement flush_kernel_vmap_range/invalidate_kernel_vmap_range
APIs but do I need to modify XFS code also ?
Where do I make call to flush_kernel_vmap_range()/
invalidate_kernel_vmap_range() in XFS code ?

Also I wish to understand why this problem is not occuring on ARM cortex-A8,
I check the code it does not implement above API's.

[-- Attachment #1.2: Type: text/html, Size: 404 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]

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

Re: XFS: bad clientid on recovery on MIPS (VIPT cache)

[Christoph Hellwig]

On Thu, Oct 21, 2010 at 06:57:15PM +0530, Ajeet Yadav wrote:
> Thanks for response,
> 
> Linux kernel I am using is 2.6.30, where as XFS I have ported until 2.6.34
> on given kernel.
> Do you think I need the mentioned API
> flush_kernel_vmap_range/invalidate_kernel_vmap_range in 2.6.30.9 as well.I
> will be grateful if you can provide me sample code for the above API.

I don't really know how to implement it - it's up to the cache
architecture.  Take a look at the existing implementations in 2.6.34+
kernels and possibly ask on the Linux-mips mainglinglist how to
implement it.

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

Re: XFS: bad clientid on recovery on MIPS (VIPT cache)

[Ajeet Yadav]

Hi,
You are using which kernel version ? because this is fixed in XFS in
kernel 2.6.34
http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=commit;h=73c77e2ccc14413c232c3e0b3aa43a0c4b72ec70

but for this patch to work correctly, yer you need to provide the
architecture dependent definition of invalidate_kernel_vmap_range() /
flush_kernel_vmap_range() and ARCH_HAS_FLUSH_KERNEL_DCACHE_PAGE,
similar to this patch

http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=commit;h=252a9afff76097667429b583e8b5b170b47665a4
http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=commit;h=73be1591579084a8103a7005dd3172f3e9dd7362

Note: include/linux/highmem.h provide dummy definitions if
architecture does not define them

#ifndef ARCH_HAS_FLUSH_KERNEL_DCACHE_PAGE
static inline void flush_kernel_dcache_page(struct page *page)
{
}
static inline void flush_kernel_vmap_range(void *vaddr, int size)
{
}
static inline void invalidate_kernel_vmap_range(void *vaddr, int size)
{
}
#endi




On Fri, Jan 6, 2012 at 3:44 PM, Tony Lu <zlu@tilera.com> wrote:
> Hi, Ajeet
>
> Sorry to bother you. By googling, I found that I am encountering the same XFS umount issue on TILE architecture. And I noticed that somebody suggested that other architectures like ARM, MIPS need to implement the following functions to fix this issue.
>
> flush_kernel_dcache_page()
> flush_kernel_vmap_range()
> void invalidate_kernel_vmap_range()
>
> I am not sure if these functions can really fix this issue, since I implemented these functions for TILE architecture, but did not fix it.
>
> So I really want to know that if you implemented these functions for MIPS to fix this issue. Or is there other method to fix this issue?
>
> I would be very appreciated for any feedback from you.
>
> Thanks
> -Tony
>
>>Dear member,
>>If I remove USB flash storage from PC/ARM/MIPS target (i.e without umount) while >copying file to XFS partition and connect it to MIPS target I always get
>>XFS: xlog_recover_process_data: bad clientid
>>XFS: log mount/recovery failed: error 5
>>XFS: log mount failed
>>This problem does not occur, if I connect the same USB flash to PC/ARM target.
>>I have tested this on 2.6.30 - 2.6.34 (It everywhere when concerend with MIPS)
>>
>>I had two workaround to avoid this problem on MIPS, but I wish to know the exact >reason of this problme on MIPS.
>>I am really tired and giving up, so finally thought of taking your help, your >guidence can help me.
>>
>>1. __flush_cache_all() at the begining of each iteration of while loop in >function xlog_recover_process_data().
>>
>>     while ((dp < lp) && num_logops) {
>>+       __flush_cache_all() ;
>>         ASSERT(dp + sizeof(xlog_op_header_t) <= lp);
>>         ohead = (xlog_op_header_t *)dp;
>>         dp += sizeof(xlog_op_header_t);
>>         if (ohead->oh_clientid != XFS_TRANSACTION &&
>>             ohead->oh_clientid != XFS_LOG) {
>>             xlog_warn(
>>             "XFS: xlog_recover_process_data: bad clientid")
>>
>>OR
>>
>>2. Provide new buffer in each call to xlog_bread in function >xlog_do_recovery_pass().
>>
>>          if (error)
>>              goto bread_err2;
>>          /* blocks in data section */
>>          bblks = (int)BTOBB(be32_to_cpu(rhead->h_len));
>>+        xlog_put_bp(dbp);
>>+        dbp = xlog_get_bp(log, BTOBB(h_size));
>>          error = xlog_bread(log, blk_no + hblks, bblks, dbp,
>>                                     &offset);
>>          if (error)
>>              goto bread_err2;
>>
>>WIth Regards
>>Ajeet Yadav

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

Re: XFS: bad clientid on recovery on MIPS (VIPT cache)

[Ajeet Yadav]

Yes I implemented these definitions for MIPS, without them this
problem will continue to occur.

On Mon, Jan 9, 2012 at 12:52 PM, Ajeet Yadav <ajeet.yadav.77@gmail.com> wrote:
> Hi,
> You are using which kernel version ? because this is fixed in XFS in
> kernel 2.6.34
> http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=commit;h=73c77e2ccc14413c232c3e0b3aa43a0c4b72ec70
>
> but for this patch to work correctly, yer you need to provide the
> architecture dependent definition of invalidate_kernel_vmap_range() /
> flush_kernel_vmap_range() and ARCH_HAS_FLUSH_KERNEL_DCACHE_PAGE,
> similar to this patch
>
> http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=commit;h=252a9afff76097667429b583e8b5b170b47665a4
> http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=commit;h=73be1591579084a8103a7005dd3172f3e9dd7362
>
> Note: include/linux/highmem.h provide dummy definitions if
> architecture does not define them
>
> #ifndef ARCH_HAS_FLUSH_KERNEL_DCACHE_PAGE
> static inline void flush_kernel_dcache_page(struct page *page)
> {
> }
> static inline void flush_kernel_vmap_range(void *vaddr, int size)
> {
> }
> static inline void invalidate_kernel_vmap_range(void *vaddr, int size)
> {
> }
> #endi
>
>
>
>
> On Fri, Jan 6, 2012 at 3:44 PM, Tony Lu <zlu@tilera.com> wrote:
>> Hi, Ajeet
>>
>> Sorry to bother you. By googling, I found that I am encountering the same XFS umount issue on TILE architecture. And I noticed that somebody suggested that other architectures like ARM, MIPS need to implement the following functions to fix this issue.
>>
>> flush_kernel_dcache_page()
>> flush_kernel_vmap_range()
>> void invalidate_kernel_vmap_range()
>>
>> I am not sure if these functions can really fix this issue, since I implemented these functions for TILE architecture, but did not fix it.
>>
>> So I really want to know that if you implemented these functions for MIPS to fix this issue. Or is there other method to fix this issue?
>>
>> I would be very appreciated for any feedback from you.
>>
>> Thanks
>> -Tony
>>
>>>Dear member,
>>>If I remove USB flash storage from PC/ARM/MIPS target (i.e without umount) while >copying file to XFS partition and connect it to MIPS target I always get
>>>XFS: xlog_recover_process_data: bad clientid
>>>XFS: log mount/recovery failed: error 5
>>>XFS: log mount failed
>>>This problem does not occur, if I connect the same USB flash to PC/ARM target.
>>>I have tested this on 2.6.30 - 2.6.34 (It everywhere when concerend with MIPS)
>>>
>>>I had two workaround to avoid this problem on MIPS, but I wish to know the exact >reason of this problme on MIPS.
>>>I am really tired and giving up, so finally thought of taking your help, your >guidence can help me.
>>>
>>>1. __flush_cache_all() at the begining of each iteration of while loop in >function xlog_recover_process_data().
>>>
>>>     while ((dp < lp) && num_logops) {
>>>+       __flush_cache_all() ;
>>>         ASSERT(dp + sizeof(xlog_op_header_t) <= lp);
>>>         ohead = (xlog_op_header_t *)dp;
>>>         dp += sizeof(xlog_op_header_t);
>>>         if (ohead->oh_clientid != XFS_TRANSACTION &&
>>>             ohead->oh_clientid != XFS_LOG) {
>>>             xlog_warn(
>>>             "XFS: xlog_recover_process_data: bad clientid")
>>>
>>>OR
>>>
>>>2. Provide new buffer in each call to xlog_bread in function >xlog_do_recovery_pass().
>>>
>>>          if (error)
>>>              goto bread_err2;
>>>          /* blocks in data section */
>>>          bblks = (int)BTOBB(be32_to_cpu(rhead->h_len));
>>>+        xlog_put_bp(dbp);
>>>+        dbp = xlog_get_bp(log, BTOBB(h_size));
>>>          error = xlog_bread(log, blk_no + hblks, bblks, dbp,
>>>                                     &offset);
>>>          if (error)
>>>              goto bread_err2;
>>>
>>>WIth Regards
>>>Ajeet Yadav

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

RE: XFS: bad clientid on recovery on MIPS (VIPT cache)

[Tony Lu]

Thanks for your kindly help, Ajeet.

I am using 2.6.38.6. 

>-----Original Message-----
>From: Ajeet Yadav [mailto:ajeet.yadav.77@gmail.com]
>Sent: Monday, January 09, 2012 3:28 PM
>To: Tony Lu; xfs@oss.sgi.com
>Subject: Re: XFS: bad clientid on recovery on MIPS (VIPT cache)
>
>Yes I implemented these definitions for MIPS, without them this
>problem will continue to occur.
>
>On Mon, Jan 9, 2012 at 12:52 PM, Ajeet Yadav <ajeet.yadav.77@gmail.com> wrote:
>> Hi,
>> You are using which kernel version ? because this is fixed in XFS in
>> kernel 2.6.34
>>
>http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=commit;
>h=73c77e2ccc14413c232c3e0b3aa43a0c4b72ec70
>>
>> but for this patch to work correctly, yer you need to provide the
>> architecture dependent definition of invalidate_kernel_vmap_range() /
>> flush_kernel_vmap_range() and ARCH_HAS_FLUSH_KERNEL_DCACHE_PAGE,
>> similar to this patch
>>
>>
>http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=commit;
>h=252a9afff76097667429b583e8b5b170b47665a4
>>
>http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=commit;
>h=73be1591579084a8103a7005dd3172f3e9dd7362
>>
>> Note: include/linux/highmem.h provide dummy definitions if
>> architecture does not define them
>>
>> #ifndef ARCH_HAS_FLUSH_KERNEL_DCACHE_PAGE
>> static inline void flush_kernel_dcache_page(struct page *page)
>> {
>> }
>> static inline void flush_kernel_vmap_range(void *vaddr, int size)
>> {
>> }
>> static inline void invalidate_kernel_vmap_range(void *vaddr, int size)
>> {
>> }
>> #endi
>>
>>
>>
>>
>> On Fri, Jan 6, 2012 at 3:44 PM, Tony Lu <zlu@tilera.com> wrote:
>>> Hi, Ajeet
>>>
>>> Sorry to bother you. By googling, I found that I am encountering the same
>XFS umount issue on TILE architecture. And I noticed that somebody suggested
>that other architectures like ARM, MIPS need to implement the following
>functions to fix this issue.
>>>
>>> flush_kernel_dcache_page()
>>> flush_kernel_vmap_range()
>>> void invalidate_kernel_vmap_range()
>>>
>>> I am not sure if these functions can really fix this issue, since I implemented
>these functions for TILE architecture, but did not fix it.
>>>
>>> So I really want to know that if you implemented these functions for MIPS
>to fix this issue. Or is there other method to fix this issue?
>>>
>>> I would be very appreciated for any feedback from you.
>>>
>>> Thanks
>>> -Tony
>>>
>>>>Dear member,
>>>>If I remove USB flash storage from PC/ARM/MIPS target (i.e without umount)
>while >copying file to XFS partition and connect it to MIPS target I always get
>>>>XFS: xlog_recover_process_data: bad clientid
>>>>XFS: log mount/recovery failed: error 5
>>>>XFS: log mount failed
>>>>This problem does not occur, if I connect the same USB flash to PC/ARM target.
>>>>I have tested this on 2.6.30 - 2.6.34 (It everywhere when concerend with MIPS)
>>>>
>>>>I had two workaround to avoid this problem on MIPS, but I wish to know the
>exact >reason of this problme on MIPS.
>>>>I am really tired and giving up, so finally thought of taking your help, your
>>guidence can help me.
>>>>
>>>>1. __flush_cache_all() at the begining of each iteration of while loop in
>>function xlog_recover_process_data().
>>>>
>>>>     while ((dp < lp) && num_logops) {
>>>>+       __flush_cache_all() ;
>>>>         ASSERT(dp + sizeof(xlog_op_header_t) <= lp);
>>>>         ohead = (xlog_op_header_t *)dp;
>>>>         dp += sizeof(xlog_op_header_t);
>>>>         if (ohead->oh_clientid != XFS_TRANSACTION &&
>>>>             ohead->oh_clientid != XFS_LOG) {
>>>>             xlog_warn(
>>>>             "XFS: xlog_recover_process_data: bad clientid")
>>>>
>>>>OR
>>>>
>>>>2. Provide new buffer in each call to xlog_bread in function
>>xlog_do_recovery_pass().
>>>>
>>>>          if (error)
>>>>              goto bread_err2;
>>>>          /* blocks in data section */
>>>>          bblks = (int)BTOBB(be32_to_cpu(rhead->h_len));
>>>>+        xlog_put_bp(dbp);
>>>>+        dbp = xlog_get_bp(log, BTOBB(h_size));
>>>>          error = xlog_bread(log, blk_no + hblks, bblks, dbp,
>>>>                                     &offset);
>>>>          if (error)
>>>>              goto bread_err2;
>>>>
>>>>WIth Regards
>>>>Ajeet Yadav

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

Re: XFS: bad clientid on recovery on MIPS (VIPT cache)

[Christoph Hellwig]

On Mon, Jan 09, 2012 at 12:58:22PM +0530, Ajeet Yadav wrote:
> Yes I implemented these definitions for MIPS, without them this
> problem will continue to occur.

Btw, Linux 3.2 finally has a version of the helpers in mainline.

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