All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oren Laadan <orenl@cs.columbia.edu>
To: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
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 10:52:36 -0400	[thread overview]
Message-ID: <4C18E534.80700@cs.columbia.edu> (raw)
In-Reply-To: <1274836063-13271-4-git-send-email-sukadev@linux.vnet.ibm.com>



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 ?

> 
> 	- 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 ?)

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.


  parent reply	other threads:[~2010-06-16 14:52 UTC|newest]

Thread overview: 39+ 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
     [not found]     ` <20100526135256.GA25799-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2010-05-26 17:14       ` Sukadev Bhattiprolu
     [not found]   ` <1274836063-13271-2-git-send-email-sukadev-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2010-05-26 13:52     ` Serge E. Hallyn
     [not found] ` <1274836063-13271-1-git-send-email-sukadev-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2010-05-26  1:07   ` Sukadev Bhattiprolu
2010-05-26  1:07   ` [RFC][PATCH 2/3][cr][v2]: Checkpoint/restart file leases Sukadev Bhattiprolu
2010-05-26  1:07   ` [RFC][PATCH 3/3][cr][v2]: fileleases: C/R of an in-progress lease Sukadev Bhattiprolu
2010-05-26  1:07 ` [RFC][PATCH 2/3][cr][v2]: Checkpoint/restart file leases Sukadev Bhattiprolu
     [not found]   ` <1274836063-13271-3-git-send-email-sukadev-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2010-06-15  4:40     ` Oren Laadan
2010-06-15  4:40   ` Oren Laadan
     [not found]     ` <4C170430.2030708-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>
2010-07-30 19:16       ` Sukadev Bhattiprolu
2010-07-30 19:16     ` Sukadev Bhattiprolu
     [not found]       ` <20100730191607.GA16238-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2010-07-30 19:45         ` Oren Laadan
2010-07-30 19:45       ` Oren Laadan
2010-07-30 21:37         ` john stultz
     [not found]           ` <1280525871.2451.23.camel-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
2010-07-30 22:32             ` Oren Laadan
2010-07-30 22:32           ` Oren Laadan
     [not found]             ` <4C5352EF.9080601-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>
2010-07-31  0:35               ` Sukadev Bhattiprolu
2010-07-31  0:35             ` Sukadev Bhattiprolu
2010-07-31  1:36               ` Matt Helsley
     [not found]               ` <20100731003504.GA3544-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2010-07-31  1:36                 ` Matt Helsley
2010-07-31  4:52                 ` Oren Laadan
2010-07-31  4:52               ` Oren Laadan
     [not found]         ` <4C532BC9.6050109-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>
2010-07-30 21:37           ` john stultz
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
     [not found]     ` <20100616111843.GA15054-yetKDKU6eevNLxjTenLetw@public.gmane.org>
2010-06-16 15:08       ` Oren Laadan
2010-06-16 17:46       ` Matt Helsley
2010-06-16 17:46     ` Matt Helsley
     [not found]   ` <1274836063-13271-4-git-send-email-sukadev-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2010-06-15  4:43     ` Oren Laadan
2010-06-16 11:18     ` Jamie Lokier
2010-06-16 14:52     ` Oren Laadan
2010-06-16 14:52   ` Oren Laadan [this message]
     [not found]     ` <4C18E534.80700-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>
2010-06-16 19:57       ` Sukadev Bhattiprolu
2010-06-16 19:57     ` Sukadev Bhattiprolu

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=4C18E534.80700@cs.columbia.edu \
    --to=orenl@cs.columbia.edu \
    --cc=containers@lists.linux-foundation.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=matthew@wil.cx \
    --cc=matthltc@us.ibm.com \
    --cc=serue@us.ibm.com \
    --cc=sukadev@linux.vnet.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.