Lustre devel - Dec 2006 - [Bug 4778] filter.c:1869:filter_should_precreate(): ASSERTION(diff >= 0) failed:3310526 - 3315096 = -4570

Please don''t reply to lustre-devel. Instead, comment in Bugzilla by
using the following link:
https://bugzilla.lustre.org/show_bug.cgi?id=4778

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #8969|review?(green@clusterfs.com)|
               Flag|                            |


(From update of attachment 8969)
looks ok.
should be landed to 1.4.9

Please don''t reply to lustre-devel. Instead, comment in Bugzilla by
using the following link:
https://bugzilla.lustre.org/show_bug.cgi?id=4778



(In reply to comment #150)
> (From update of attachment 8969)
> looks ok.
> should be landed to 1.4.9
landed to b1_4
>

Please don''t reply to lustre-devel. Instead, comment in Bugzilla by
using the following link:
https://bugzilla.lustre.org/show_bug.cgi?id=4778



Created an attachment (id=9228)
Please don''t reply to lustre-devel. Instead, comment in Bugzilla by
using the following link:
 --> (https://bugzilla.lustre.org/attachment.cgi?id=9228&action=view)
minor remaining cleanups for inspection

Before I was testing this bug I was having repeated problems with precreate
hitting LBUGs due to existing objects, and I thought I was hitting this bug. 
It
turned out to be a bad interaction with one of the regression test
failure-injection hooks and the async object creates from bug 4900 which allow
testing to continue while one OST is still doing object recovery.

Attached is a small patch that disables the OBD_FAIL_OST_ENOENT hook if we are
doing orphan recovery to avoid skipping objects during orphan cleanup and then
tripping the "Serious error: object already exists" assertion later.

Also, in filter_handle_precreate() it skips orphan destroy requests from
"old"
connections, similar to what is in the other branch of the "if" in the
previous

patch, since it doesn''t make sense to handle either of them if there
was a
reconnection and the request has been resent.

It also clarifies some of the OSC-side debug messages to avoid confusing the
"last used" and "next to use" values.

Please don''t reply to lustre-devel. Instead, comment in Bugzilla by
using the following link:
https://bugzilla.lustre.org/show_bug.cgi?id=4778

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #9228|review?(green@clusterfs.com)|review+
               Flag|                            |


(From update of attachment 9228)
Looks good. Zam,please take a look and land if you think all is fine as well

Please don''t reply to lustre-devel. Instead, comment in Bugzilla by
using the following link:
https://bugzilla.lustre.org/show_bug.cgi?id=4778

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Status Whiteboard|2006-12-28: Patch landed on |2006-12-31: patch landed on
                   |b1_4 for 1.4.9; patch       |b1_4 for Lustre 1.4.9;
                   |already landed for 1.6      |requires confirmation of
                   |                            |landing on b1_5


Comment Tags: Status Change

2006-12-31: patch landed on b1_4 for Lustre 1.4.9; requires confirmation of
landing on b1_5

Zam,

This needs to be landed on b1_5 as well, for Lustre 1.6.0

Thanks,
Bojanic

Please don''t reply to lustre-devel. Instead, comment in Bugzilla by
using the following link:
https://bugzilla.lustre.org/show_bug.cgi?id=4778



Created an attachment (id=9317)
Please don''t reply to lustre-devel. Instead, comment in Bugzilla by
using the following link:
 --> (https://bugzilla.lustre.org/attachment.cgi?id=9317&action=view)
remaining fixes and cleanups to land on b1_5

fixes and cleanups still not present in b1_5