Details
-
New Feature
-
Resolution: Fixed
-
Minor
-
Lustre 2.4.0
-
5813
Attachments
Issue Links
Activity
I appriciate your consideration!
But I'm afraid to say that, as you said, my patch depends os some FEFS-specific changes, so I think I'd better collect some codes, change them and apply them for, at least, 1.8.8. I believe that you'll find it easer when I do it than when I don't.
I'll upload the patch within today in JST, please wait for a while.
and thank you for your consideration again !!
Attaching an existing FEFS patch here would be more economical than porting it to b2_3, which no longer accepts any changes. If it depends too much on other FEFS-specific changes, master is where it should be ported to. (I was just trying to minimise your effort before we are sure whether it is the right way to go.)
Does you mean that you're OK if I upload a patch for FEFS ?
Generally, only master accepts new features. Also, I would post a minimum version that shows the design first, before spending too much time polishing the details.
> Administratively triggering pings via procfs file "ping" before each job starts may help reduce the number of evictions seen by applications.
Yes, you're right. Actually We've workarounded this problem with some other new features of FEFS, running some scripts and "lfs df" on evicted clients which is triggerd by Fujitsu system management software. But I believe that it's more convenient if a ping can be driven and sent by Lustre itself.
> please post a link here
I'll appriciate it! now I have only a patch for FEFS. So I'll convert its version for Lustre-2.3.x, Please wait for a while.
Hi Nozaki-san,
The case you described is real. Ideally, an installation shall be tuned to a point where no evictions happen during normal operations (i.e., no clients miss recovery windows). But I guess that might be hard to achieve on realistic and large installations. Administratively triggering pings via procfs file "ping" before each job starts may help reduce the number of evictions seen by applications. Nevertheless, the case can not be completely eliminated this way.
If you have a patch already, please post a link here; some design thoughts would also do. Let's see if we can get some discussions going.
Hi, all. I'm a developer in Fujitsu. I'd like to let you know one thing ralated to the issue that has bothered our development team for a long time. It is that ... clients don't have the way to confirm whether or not it's already been evicted besides actually sending an rpc request. So this behavior let it often happen that an already-evicted client returns -EIO to a user application when it's first used ... even when it's evicted long time ago. I know this ploblem is inevitable as far as we use ldlm. But disable pinging makes this problem more serious issue, especially in a large environment like K.
Now I've tried to implement one function which let the server-side, which has targets, notifies clients eviction-event via MGS. And I want to cooperate with you, I mean, I want to open my prototype patch for 1.8.8 and examine it together.
Thank you.
http://review.whamcloud.com/5229
http://review.whamcloud.com/5232
http://review.whamcloud.com/5231
http://review.whamcloud.com/5009
I opened a separate ticket LU-2898 to track the issue of client eviction notification, so please use it for further discussion on this topic and let's concentrate on the disabled pinging support in this ticket.