linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
To: Oren Laadan <orenl@cs.columbia.edu>
Cc: serue@us.ibm.com, Matt Helsley <matthltc@us.ibm.com>,
	matthew@wil.cx, linux-fsdevel@vger.kernel.org,
	Containers <containers@lists.linux-foundation.org>
Subject: Re: [RFC][PATCH 3/3][cr][v2]: fileleases: C/R of an in-progress lease.
Date: Wed, 16 Jun 2010 12:57:46 -0700	[thread overview]
Message-ID: <20100616195746.GA29256@us.ibm.com> (raw)
In-Reply-To: <4C18E534.80700@cs.columbia.edu>

Oren Laadan [orenl@cs.columbia.edu] wrote:
| 
| 
| On 05/25/2010 09:07 PM, Sukadev Bhattiprolu wrote:
| > If process P1 has a F_WRLCK lease on file F1 and process P2 opens the
| > file, P2's open() blocks for lease_break_time (45 seconds) and P1 gets
| > a SIGIO to cleanup it lease in preparation for P2's open.  If the two
| > processes are checkpointed/restarted in this window, we should address
| > following two issues:
| > 
| > 	- P1 should get a SIGIO only once for the lease (i.e if P1 got the
| > 	  SIGIO before checkpoint, it should not get the SIGIO after restart).
| 
| The qualification "before" is vague in our case - a checkpoint is
| potentially a length operation, so before *which part* of the
| checkpoint you mean here ?

I should have been more specific. I meant - if P1 got the SIGIO before
freezing the container for checkpoint, it should not get the SIGIO after
restart/unfreeze. So checkpoint can take minutes, but if P2 is in the
same container and P2 is frozen too.

| > 
| > 	- If R seconds remain in the lease, P2's open should be blocked for
| > 	  at least the R seconds, so P1 has the time to clean up its lease.
| > 	  The previous patch gives P1 the entire lease_break_time but that
| > 	  can leave P2 stalled for 2*lease_break_time.
| > 
| > To address first, we add a field ->fl_break_notified to "remember" if we
| > notified the lease-holder already. We save this field in the checkpoint
| > image and when restarting, we notify the lease-holder only if this field
| > is not set.
| 
| I'm not sure I understand.
| 
| Signals are saved last, in particular they are saved after files, and
| file leases. What happens if we at checkpoint, we look at a file lease -
| we save the least_break_time, now we proceed with the checkpoint, now
| the lease expires before we are done, so we get a signal, and finally
| we save the signals. In this case, we get both an expiry time and the
| signal recorded.
| 
| (Am I mis-reading the code ?)

The signal is sent when P2 opens the file and lease-break is initiated.
No signal is sent when the lease actually expires.

So when P1 and P2 are *both frozen*, then only one of these are true right ?

	- P2 initiated the lease-break and sent the SIGIO or
	- the lease-break was not initiated at all

As youmentioned in your other email, I will look into the ctx->ktime_begin.
| 
| It seems to me that we need to mark the file lease at checkpoint to
| prevent the signal from being sent until _after_ the checkpoint ends
| (as opposed to remembering that the signal was sent). And then at the
| end of the checkpoint, iterate through the leases for each marked
| lease - remove the mark and fire the signal.
| 
| Oren.

      reply	other threads:[~2010-06-16 19:47 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-26  1:07 [RFC][PATCH 0/3][cr][v2]: Checkpoint/restart file leases Sukadev Bhattiprolu
2010-05-26  1:07 ` [RFC][PATCH 1/3][cr][v2]: Define do_setlease() Sukadev Bhattiprolu
2010-05-26 13:52   ` Serge E. Hallyn
2010-05-26 17:14     ` Sukadev Bhattiprolu
2010-05-26  1:07 ` [RFC][PATCH 2/3][cr][v2]: Checkpoint/restart file leases Sukadev Bhattiprolu
2010-06-15  4:40   ` Oren Laadan
2010-07-30 19:16     ` Sukadev Bhattiprolu
2010-07-30 19:45       ` Oren Laadan
2010-07-30 21:37         ` john stultz
2010-07-30 22:32           ` Oren Laadan
2010-07-31  0:35             ` Sukadev Bhattiprolu
2010-07-31  1:36               ` Matt Helsley
2010-07-31  4:52               ` Oren Laadan
2010-05-26  1:07 ` [RFC][PATCH 3/3][cr][v2]: fileleases: C/R of an in-progress lease Sukadev Bhattiprolu
2010-06-15  4:43   ` Oren Laadan
2010-06-16 11:18   ` Jamie Lokier
2010-06-16 15:08     ` Oren Laadan
2010-06-16 17:46     ` Matt Helsley
2010-06-16 14:52   ` Oren Laadan
2010-06-16 19:57     ` Sukadev Bhattiprolu [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100616195746.GA29256@us.ibm.com \
    --to=sukadev@linux.vnet.ibm.com \
    --cc=containers@lists.linux-foundation.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=matthew@wil.cx \
    --cc=matthltc@us.ibm.com \
    --cc=orenl@cs.columbia.edu \
    --cc=serue@us.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).