It is still busted, I've been trying to find clues as to why...
Maybe this is relevant:
Alloced OP ffff880015698000 <- doomed op for orangefs_create MAILBOX2.CPT
service_operation: orangefs_create op ffff880015698000
ffff880015698000 got past is_daemon_in_service
... lots of stuff ...
w_f_m_d returned -11 for ffff880015698000 <- first op to get EAGAIN
first client core is NOT in service
second op to get EAGAIN
...
last client core is NOT in service
... lots of stuff ...
service_operation returns to orangef_create with handle 0 fsid 0 ret 0
for MAILBOX2.CPT
I'm guessing you want me to wait to do the switching of my branch
until we fix this (last?) thing, let me know...
-Mike
On Tue, Feb 16, 2016 at 6:54 PM, Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote:
> On Tue, Feb 16, 2016 at 11:36:09PM +0000, Al Viro wrote:
>
>> I strongly suspect that this is what's missing. Could you check if it helps?
>
> BTW, I've pushed #orangefs-untested; the differences are
> * several fixes folded back into relevant commits (no point creating
> bisect hazards and making the history harder to read)
> * this thing also folded (and in fact is what you get from diffing
> that tree with your for-next)
> * commit message for bufmap rewrite supplied.
>
> Could you (assuming it works, etc.) switch your branch to that?
> git checkout for-next, git fetch from vfs.git, git diff FETCH_HEAD to
> verify that the delta is as it should be, then git reset --hard FETCH_HEAD
> and git push --force <whatever remote you are using> for-next would do it...
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
