public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: hooanon05@yahoo.co.jp
To: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [RFC 5/8] Aufs2: wbr_policy
Date: Mon, 23 Feb 2009 16:36:47 +0900	[thread overview]
Message-ID: <7805.1235374607@jrobl> (raw)
In-Reply-To: <7558.1235374266@jrobl>


> This is my second trial to ask incorporating aufs into mainline.


Policies to Select One among Multiple Writable Branches
----------------------------------------------------------------------
When the number of writable branch is more than one, aufs has to decide
the target branch for file creation or copy-up. By default, the highest
writable branch which has the parent (or ancestor) dir of the target
file is chosen (top-down-parent policy).
By user's request, aufs implements some other policies to select the
writable branch, for file creation two policies, round-robin and
most-free-space policies. For copy-up three policies, top-down-parent,
bottom-up-parent and bottom-up policies.

As expected, the round-robin policy selects the branch in circular. When
you have two writable branches and creates 10 new files, 5 files will be
created for each branch. mkdir(2) systemcall is an exception. When you
create 10 new directories, all will be created on the same branch.
And the most-free-space policy selects the one which has most free
space among the writable branches. The amount of free space will be
checked by aufs internally, and users can specify its time interval.

The policies for copy-up is more simple,
top-down-parent is equivalent to the same named on in create policy,
bottom-up-parent selects the writable branch where the parent dir
exists and the nearest upper one from the copyup-source,
bottom-up selects the nearest upper writable branch from the
copyup-source, regardless the existence of the parent dir.

There are some rules or exceptions to apply these policies.
- If there is a readonly branch above the policy-selected branch and
  the parent dir is marked as opaque (a variation of whiteout), or the
  target (creating) file is whiteout-ed on the upper readonly branch,
  then the result of the policy is ignored and the target file will be
  created on the nearest upper writable branch than the readonly branch.
- If there is a writable branch above the policy-selected branch and
  the parent dir is marked as opaque or the target file is whiteouted
  on the branch, then the result of the policy is ignored and the target
  file will be created on the highest one among the upper writable
  branches who has diropq or whiteout. In case of whiteout, aufs removes
  it as usual.
- link(2) and rename(2) systemcalls are exceptions in every policy.
  They try selecting the branch where the source exists as possible
  since copyup a large file will take long time. If it can't be,
  ie. the branch where the source exists is readonly, then they will
  follow the copyup policy.
- There is an exception for rename(2) when the target exists.
  If the rename target exists, aufs compares the index of the branches
  where the source and the target exists and selects the higher
  one. If the selected branch is readonly, then aufs follows the
  copyup policy.

  parent reply	other threads:[~2009-02-23  7:36 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-23  7:31 [RFC 0/8] Aufs2 documents hooanon05
2009-02-23  7:33 ` [RFC 1/8] Aufs2: introduction hooanon05
2009-02-23  7:34 ` [RFC 2/8] Aufs2: structure hooanon05
2009-02-23  9:13   ` Tomas M
2009-02-23  9:22     ` Tomas M
2009-02-24  8:13       ` New filesystem for Linux kernel Tomas M
2009-02-24 11:52         ` Miklos Szeredi
2009-02-24 13:18           ` hooanon05
2009-02-24 13:45             ` Tarkan Erimer
2009-02-24 13:57               ` hooanon05
2009-02-24 14:16                 ` Tarkan Erimer
2009-02-24 14:50             ` Miklos Szeredi
2009-02-24 16:26               ` hooanon05
2009-02-25 10:28                 ` Miklos Szeredi
2009-02-26  4:09                   ` hooanon05
2009-02-26  5:51               ` hooanon05
2009-02-26  5:55                 ` hooanon05
2009-02-24 14:15         ` Theodore Tso
2009-02-24 15:18           ` David P. Quigley
2009-02-24 15:41             ` hooanon05
2009-02-25 15:53               ` David P. Quigley
2009-02-26  4:21                 ` hooanon05
2009-02-25  7:31             ` Tomas M
2009-02-25  9:33               ` David Newall
2009-02-25  8:12           ` Tomas M
2009-02-26 14:31           ` Amit Kucheria
2009-02-23 14:23     ` [RFC 2/8] Aufs2: structure hooanon05
2009-02-23  7:35 ` [RFC 3/8] Aufs2: lookup hooanon05
2009-02-23  7:36 ` [RFC 4/8] Aufs2: branch hooanon05
2009-02-23  7:36 ` hooanon05 [this message]
2009-02-23  7:37 ` [RFC 6/8] Aufs2: fmode_exec hooanon05
2009-02-23  7:37 ` [RFC 7/8] Aufs2: mmap hooanon05
2009-02-23  9:18   ` Tomas M
2009-02-23 14:39     ` hooanon05
2009-02-23  7:38 ` [RFC 8/8] Aufs2: plan hooanon05
2009-02-25 17:50 ` [RFC 0/8] Aufs2 documents David P. Quigley
2009-02-25 19:07   ` Matthew Wilcox
2009-02-26  4:54   ` hooanon05
2009-02-26 17:20     ` David P. Quigley
2009-02-27 14:27       ` hooanon05
2009-02-27 18:17         ` David P. Quigley
2009-02-28  8:04           ` hooanon05

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=7805.1235374607@jrobl \
    --to=hooanon05@yahoo.co.jp \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox