All of lore.kernel.org
 help / color / mirror / Atom feed
From: sfjro@users.sourceforge.net
To: Hans-Peter Jansen <hpj@urpla.net>
Cc: aufs-users@lists.sourceforge.net, linux-unionfs@vger.kernel.org
Subject: Re: aufs as root vor openvz CT
Date: Wed, 23 Jul 2014 11:59:18 +0900	[thread overview]
Message-ID: <9782.1406084358@jrobl> (raw)
In-Reply-To: <1728348.LhyPPIypjG@xrated>


Hello Pete,
Thank you very much for your contribution.
I've repeatedly asked Sergey how to reproduce and the details, but got
no good answers. I hope your contribution will make the details clearer.


Hans-Peter Jansen:
> In order to perform a proper suspend/resume cycle, the CT has to arrange 
> everything to the state before the suspend. Therefore, they track the opened 
> files, and restore their state during resume. Layering FS (LFS) do cause 
> problems in this scenario, since files opened by them don't belong to any 
> application running in the container.

I'd ask generic questions (to anyone).
- Is such handling done in the container, or in the generic linux
  checkpoint/restart?
- If it is done in the generic feature, then is the linux
  checkpoint/restart feature specific to the containers?
- If not, we will be able to reproduce without any containers, no
  openvz, no old kernel.

As a first step, I need to know the detail steps to reproduce the
problem since I don't know much about suspend/resume.


> So, either define a special open flag for LFS internal fds, which, I guess, is 
> rather unpopular, or define a respective fcntl, that those LFS should 
> implement. Otherwise, every CT needs to detect the internal fds of every LFS 
> implementation heuristically, which is the worst solution, of course.

It depends upon how CT finds the opend files.
I have another idea.
- add a notifier-chain into the suspend feature (if there is not
  currently).
- any module who opens a file internaly regists itself to the
  notifier-chain.
- when the suspend event is notified via the notifier-chain, the module
  handle it.


J. R. Okajima

------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds

  reply	other threads:[~2014-07-23  2:59 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAKG6wnaq1BwLgMNy27i8ggzt_qMnUb0KVNQg=Z85nz1LbXttUg@mail.gmail.com>
     [not found] ` <29716.1405886425@jrobl>
     [not found]   ` <CAKG6wnYsDk8_JoG8QrHZ3ZtDicnwt__6AGTod-Ozqi5gjoZTdw@mail.gmail.com>
2014-07-22  7:32     ` aufs as root vor openvz CT Hans-Peter Jansen
2014-07-23  2:59       ` sfjro [this message]
2014-08-22 12:04         ` Sergey Korshunoff
2014-12-09 16:43           ` Sergey Korshunoff

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=9782.1406084358@jrobl \
    --to=sfjro@users.sourceforge.net \
    --cc=aufs-users@lists.sourceforge.net \
    --cc=hpj@urpla.net \
    --cc=linux-unionfs@vger.kernel.org \
    /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.