• 検索結果がありません。

目次 背景 スナップショットの概要及び実装例 ext3 スナップショットの実現動機 ext3 スナップショットの実現方針 ffs スナップショットの概要 ext3 ファイルシステムのジャーナル機能の概要 ext3 スナップショットの設計 現時点の実装とその評価 今後の課題 2005/06/01 Li

N/A
N/A
Protected

Academic year: 2021

シェア "目次 背景 スナップショットの概要及び実装例 ext3 スナップショットの実現動機 ext3 スナップショットの実現方針 ffs スナップショットの概要 ext3 ファイルシステムのジャーナル機能の概要 ext3 スナップショットの設計 現時点の実装とその評価 今後の課題 2005/06/01 Li"

Copied!
49
0
0

読み込み中.... (全文を見る)

全文

(1)

ext3ファイルシステムへの

スナップショット機能の設計と実装

NTTコムウェア株式会社

オープンソースソフトウェア推進部

前野真輝

( E-Mail:

[email protected]

)

(2)

2005/06/01

Linux Conference 2005

1

目次

背景

スナップショットの概要及び実装例

ext3スナップショットの実現動機

ext3スナップショットの実現方針

ffsスナップショットの概要

ext3ファイルシステムのジャーナル機能の概要

ext3スナップショットの設計

現時点の実装とその評価

今後の課題

(3)
(4)

2005/06/01

Linux Conference 2005

3

データ3への

ポインタ

データ3への

ポインタ

スナップショットの概要

スナップショットはある瞬間のイメージを保持

利点

: 短い時間でイメージを取得可能

スナップショット

スナップショット取得元ファイルシステム

データ1

データ2

データ3

スナップショットを取得する時

ポインタの作成のみ

データ1への

ポインタ

データ2への

ポインタ

データ3への

ポインタ

スナップショット取得後に元のFS上のデータ更新が発生する時

データ1

データ2

データ3’

データ1への

ポインタ

データ2への

ポインタ

データ3

×

更新前のデータのコピー

ポインタの変更

(5)

スナップショットの既存の実装例

NetApp社が特許を持

つWAFLを拡張

スナップショットが同じ

inode番号を持つ

FSレイヤ

(追記型(LFS))

ストレージ

システム

WAFL

(=write anywhere file layout)

スナップショット

ffsを拡張

soft updatesを利用

FSレイヤ

(更新型)

FreeBSD

NetBSD

ffs

(=BSD fast file system)

スナップショット

特徴

レイヤ

OS

名称

EMC社のSymmetrix等

の製品に採用

FSレイヤ

ストレージ

システム

SnapView

TimeFinder

Device-mapperを利用

ブロックデバイ

スレイヤ

Linux

LVM

(=logical volume manager)

(6)

2005/06/01

Linux Conference 2005

5

ext3スナップショットの実現動機

現在

Linux上で有力なのはLVMスナップショット

ブロックデバイスレイヤでの実装

スナップショット専用領域を別に確保して差分情報を格納

chunk単位(=大きなサイズ)でスナップショット取得後の更新前

データのコピー

(=Copy-On-Write)して保護

利点

スナップショット取得時に存在したデータの更新が速い

スナップショットとして利用できる量を自由に決定可能

欠点

FSレベルでみると、更新されていないデータもコピーが行われる

ため、余分なコピーが発生し、余分にディスク容量を消費

利用できる量を超えるとスナップショットは消滅

•FSレイヤで実装する事により欠点を解決できるのではないか

•現在Linuxで標準FSであるext3FSへの実装

(7)

ext3スナップショットの実現目標

スナップショットを通常通り

ext3FSとしてマウントし

て利用可能

ジャーナリング

FSでスナップショット機能が実装可能で

ある事を実証する

スナップショット数に

FSレイアウト上の制限を付け

ない

スーパブロックにスナップショット

inode番号を埋め込む

事は受け入れない

短時間での

(スナップショットの)クラッシュリカバリ

ext3FSの特徴を失わない

(8)

ext3スナップショット

実現方針

(9)

ext3スナップショットの実現方針

ffsとext3の関係

BSD

Linux

ffs

ext2FS

ext3FS

ffsを元に設計

ジャーナル機能付加

ffs snapshot

ffs snapshotを元に設計

ext3 snapshot

スナップショット機能付加

•ext3スナップショットもffsスナップショットを基本にする

•ただしext3FSのジャーナリングに関する制限を克服す

る実装が必要

soft updates(soft dep)を利用して

スナップショット機能付加

(10)

2005/06/01

Linux Conference 2005

9

ext3スナップショットの実現方針

ffsとext3の関係

BSD

Linux

ffs

ext2FS

ext3FS

ffsを元に設計

ジャーナル機能付加

ffs snapshot

soft updates(soft dep)を利用して

スナップショット機能付加

ext3 snapshot

ffs snapshotを元に設計

スナップショット機能付加

•ext3スナップショットもffsスナップショットを基本にする

•ただしext3FSのジャーナリングに関する制限を克服す

る実装が必要

まず

ffsスナップショットとext3FSのジャーナル機能について説明する

(11)
(12)

2005/06/01

Linux Conference 2005

11

ffsスナップショットの概要

あらゆる更新操作についてデータを書き換えた後

にポインタを変更する

soft updatesの機構を利用

inode更新, 直接/間接ブロック確保, truncate

down/up, ディレクトリ/エントリの追加/削除等のあらゆ

る更新操作のデータ依存関係を考慮

ブロック書き出し時に

Copy-On-Writeする事により、

スナップショット取得時のデータを保護

前述した動作と同じ

データ1

データ2

データ3’

データ1への

ポインタ

データ2への

ポインタ

データ3への

ポインタ

データ3

×

データ3への

ポインタ

更新前のデータのコピー

ポインタの変更

(13)

1

2

4

ffsスナップショットのデータ退避先とその利用

Copy-On-Writeしたデータ退避先は取得元FS内の通常ファイル(=スナッ

プショットファイル

: 取得元FSと見かけ同容量のsparseファイル)へ行う

スナップショット取得元

FS

スナップショットファイル

vnode仮想デバイス

(=スナップショット用デバイス)

0

0

1’

1

2’

2

3

3

4’

4

5

5

6

6

1

2

4

= スナップショット取得後に

更新されていないデータブロック

: スナップショットファイルにブロックが存

在すればスナップショットファイルから、存在

しなければ取得元

FSから読み出し

= スナップショット取得後に

更新されたデータブロック

: スナップショット取得後から更新される

ブロックを更新前にスナップショットファイル

へコピー

(=Copy-On-Write)

: vnode仮想デバイスへスナップショット

ファイルと取得元

FSを関連付ける

: vnode仮想デバイスをマウントしスナッ

プショットを

FSとして利用

(14)

ext3ファイルシステム

(ジャーナル機能)

(15)

ext3FSのジャーナルの仕組みとその役割

複数のブロックにわたる不可分な変更内容をまず

ジャーナル領域へ書き出す事で、システムクラッ

シュしても、ジャーナルリプレイにより高速なリカバ

リを実現する

ジャーナルも通常ファイルと同様に

inodeやデータブロッ

クを持つ

ジャーナルは別デバイスに確保する事も可能

ジャーナル

ext3FS

実際のデータ

:

データ変更要求

:

変更内容を先に書き出す

:

実際のデータを書き出す

’ :

③中にクラッシュした場合ジャーナル内のデータを利用してリカバリする

(16)

2005/06/01

Linux Conference 2005

15

ext3FSのジャーナルモード

data=journal

データを含む全ての変更をジャーナルする

data=ordered (ext3のデフォルトモード)

通常ファイルのデータ以外

(inodeや間接ブロックやビッ

トマップブロックなどのメタデータ

)に対しジャーナルする

ジャーナルを書き出す前に実際の通常ファイルのデー

タを書き出す

data=writeback

通常ファイルのデータ以外

(メタデータ)に対しジャーナ

ルする

ジャーナルと通常ファイルのデータの書き出し順序は問

わない

(17)

ffs soft updatesとext3FSのディスク書き出し依存関係

メタデータ

データ

ジャーナル

data=ordered

data=journal

data=journal

ディスク書き込み依存関係

(Bを書き出し完了後, Aを書き出す)

ジャーナル解放依存関係

(Bを書き出し完了後, Aを解放する)

A

B

A

B

data=journal : メタデータとデータ

それ以外: メタデータのみ

•soft updatesは全ての追加/更新/削除の各

操作に対して細かい単位でディスク書き出し

の依存関係を追跡する必要有

•ジャーナルはsoft updatesに比べてディスク

書き出しの依存関係が大幅に単純化

ext3ジャーナル

ffs soft updates

(18)

ext3スナップショット

設計

(19)

ext3スナップショットの実現方針

基本的な考え方は

ffsスナップショットと同様

スナップショットの作成

スナップショットを取得する元のパーティション内へ見かけ上

同容量のスナップショットファイルを作成

スナップショットの保護

ファイルシステム上のデータが更新される直前にスナップ

ショット取得時のデータをスナップショットファイルへ退避

(=Copy-On-Write)

スナップショットの利用

スナップショットファイルを関連付けたスナップショット専用の

ブロックデバイスからスナップショットを利用

基本的な考え方は

ffsスナップショットと同様で既に動作を説明済みな

ので、処理の流れに沿うのではなく、各機能に焦点を当てて説明する

(20)

2005/06/01

Linux Conference 2005

19

ext3スナップショットへ必要な機能

ffsスナップショットと異なる方式で実装する機能

Copy-On-Write

beforeイメージジャーナル

スナップショットファイルの

delayed allocation

クラッシュリカバリ

ffsスナップショットと同じ考え方で実装する機能

スナップショット初期化

(スナップショットファイル作成)

ブロック解放抑止

スナップショット用デバイス

(21)

必要な機能

: Copy-On-Write

スナップショットのデータの保護

実際のデータが更新される前にスナップショット取得時

のデータをスナップショットファイルへコピーする

(=Copy-On-Write)

ext3FS with ext3スナップショット

スナップショットファイル

:

データ更新要求

メタデータ

データ

メタデータ

データ

:

スナップショット

取得時の

データを退避

:

スナップショットのメタデータの更新

:

実際のデータの

更新

(22)

2005/06/01

Linux Conference 2005

21

必要な機能

: Copy-On-Write

問題点

ffsスナップショットではディスクブロックの書き出し前に

Copy-On-Writeしているが、ext3FSでは既にジャーナル

領域に書き出されてしまった後である

その間にクラッシュするとスナップショットデータはジャーナル

リプレイにより失われる

解決策

ディスクブロック書き出し時ではなく、データ更新時に

Copy-On-Writeする

(23)

必要な機能

: Copy-On-Write

Copy-On-Writeのタイミング

メタデータ更新の直前

ジャーナルの変更前処理

inode bitmapによるinodeブロック内クリア処理

データ更新の直前

write()処理

mmap()処理

direct_IO()処理

ブロック境界でない

truncate down処理

(24)

2005/06/01

Linux Conference 2005

23

必要な機能

: beforeイメージジャーナル

クラッシュ時のスナップショットのデータの保護

スナップショット取得時のメタデータとデータをジャーナ

ルへ書き出す

(=ジャーナル量増加)

ただし、ジャーナルモードに依存せずにそれを行わなければ

ならない

メタデータ

データ

ジャーナル

data=ordered

data=journal

data=journal

data=journal : メタデータとデータ

それ以外: メタデータのみ

スナップショット取得時の

メタデータとデータ

(=Copy-On-Writeされるデータ)

ディスク書き込み依存関係

(Bを書き出し完了後, Aを書き出す)

ジャーナル解放依存関係

(Bを書き出し完了後, Aを解放する)

A

B

A

B

スナップショット取得時に存在した

データが変更される場合

(25)

必要な機能

: beforeイメージジャーナル

問題点

data=orderedではジャーナルよりもデータへの書き出

しを先に行わねばならず、既存のジャーナルへスナップ

ショットのデータを追加する方針には問題がある

data=journalでは問題なく、data=writebackでは新たな制約

を設ければ良い

メタデータ

データ

ジャーナル

data=ordered

実際のメタデータ

スナップショット取得時のメタデータとデータ

実際のデータ変更中にシステムクラッシュす

ると、ジャーナル中にあるスナップショットの

データはまだディスクに書き出されておらず

消滅してしまう

(=Copy-On-Writeされるデータ)

(26)

2005/06/01

Linux Conference 2005

25

必要な機能

: beforeイメージジャーナル

解決策

従来のジャーナルとは別のスナップショット用のジャー

ナル

(=beforeイメージジャーナル)を設ける

従来のジャーナルは

afterイメージジャーナルと呼ぶ

メタデータ

データ

afterイメージジャーナル

data=journal

data=journal

data=ordered

スナップショットファイル

メタデータ

COW

COW

(

取得元

FS

上にある

)

スナップショット

ファイル自身の

メタデータを指す

スナップショット取得時のメタデータとデータ

(=Copy-On-Writeされるデータ)

beforeイメージジャーナル

スナップショットファイル

データ

(27)

スナップショットファイル

メタデータ

スナップショットファイル

データ

Copy-On-Writeとbeforeイメージジャーナル

Copy-On-Write処理によるスナップショット取得時

のデータの流れ

メタデータ

データ

beforeイメージジャーナル

スナップショットファイル

メタデータ

スナップショットファイル

データ

afterイメージジャーナル

①:

afterイメージジャーナル(data=ordered

の場合はデータ

)を書き出す前にスナップ

ショット取得時の情報をコピー

COW

COW

①の前後(スナップショット取得時の情報

が更新されるのを検知した後):

スナップショット取得時の情報を各々の

スナップショットファイルへコピー

COW

COW

(28)

2005/06/01

Linux Conference 2005

27

スナップショットファイル

データ

スナップショットファイル

メタデータ

COW

COW

スナップショットファイル

メタデータ

スナップショットファイル

データ

COW

COW

スナップショットファイルの

delayed allocation

複数スナップショット取得時の問題点

スナップショット数が増えれば増えるほど、システムコー

ルを完了するための変更ブロック数が増加し、

afterイ

メージジャーナル量が多くなり過ぎ、処理が破綻

メタデータ

データ

beforeイメージジャーナル

スナップショットファイル

メタデータ

スナップショットファイル

データ

afterイメージジャーナル

COW

COW

ジャーナル量がスナップショッ

ト数に比例し多くなり過ぎる

(29)

スナップショットファイルの

delayed allocation

解決策

ブロック割り当て処理を

write()時に行うのではなく、

ページ書き出し時に行うようにする

Copy-On-Write時に(afterイメージ)ジャーナルを必要としなく

なる

スナップショットファイル

データ

スナップショットファイル

メタデータ

COW

COW

スナップショットファイル

メタデータ

スナップショットファイル

データ

COW

COW

メタデータ

データ

beforeイメージジャーナル

スナップショットファイル

メタデータ

スナップショットファイル

データ

afterイメージジャーナル

COW

COW

スナップショットファイルに対して

delayed allocationを行う

(30)

2005/06/01

Linux Conference 2005

29

必要な機能

: クラッシュリカバリ

スナップショットの回復処理の追加

クラッシュリカバリの流れ

従来のジャーナルのリプレイ

従来のジャーナルの有効化

クラッシュ時に

truncate/unlink中であったファイルの処理

スナップショットの回復処理

•beforeイメージジャーナルからスナップショットファイ

ルに対して更新

(31)

必要な機能

: スナップショット初期化

スナップショットファイル作成

見かけ上

FSと同容量のファイルを作成

FSを停止させてメタデータをコピー

ext3FS with ext3スナップショット

:

スナップショット取得要求

メタデータ

データ

スナップショットファイル

:

スナップショットファイル作成

メタデータ

データ

:

メタデータのコピー

:

ファイルシステム停止

この時間がmkfs.ext3程度掛かってしまう(=FS停止時間が長すぎる)

: ファイルシステム再開

Any: FS

への要求

(32)

2005/06/01

Linux Conference 2005

31

必要な機能

: スナップショット初期化

解決策

FSの停止時間を短くするために前もってメタデータをコ

ピーし、コピー中に変化したメタデータだけを

FSを停止さ

せて再度コピー

ext3FS with ext3スナップショット

:

スナップショット取得要求

メタデータ

データ

スナップショットファイル

:

スナップショットファイル作成

メタデータ

データ

:

メタデータのコピーと

変更追跡

:

ファイルシステム停止

⑥: ファイルシステム再開

Any: FS

への要求

⑤: メタデータのコピー中に

変更されたメタデータの

再コピー

(33)

必要な機能

: ブロック解放抑止

ブロック解放時のスナップショットのデータの保護

スナップショット取得後は、スナップショットが該当ブロッ

クを参照している可能性があり、もし参照している場合

はブロック解放しない

ブロック解放抑止のタイミング

ブロック解放時

free_blocks()処理

Copy-On-Write時と異なり、解放処理はジャーナルされ

ない

(必要がない)ために解放抑止処理はブロック解放

時で問題無い

(34)

2005/06/01

Linux Conference 2005

33

必要な機能

: スナップショット用デバイス

スナップショットの利用

スナップ取得元デバイスのデータとスナップショットファ

イルを選択的に読み込む専用ブロックデバイスから利

1

2

4

スナップショット取得元

FS

スナップショットファイル

スナップショット専用

ブロックデバイス

0

0

1’

1

2’

2

3

3

4’

4

5

5

6

6

1

2

4

= スナップショット取得後に

更新されていないデータブロック

= スナップショット取得後に

更新されたデータブロック

(35)

ext3スナップショット

現時点の実装状況

(36)

2005/06/01

Linux Conference 2005

35

現時点での実装

スナップショットの基本動作は実装完了

FS毎に1つのスナップショットが取得でき、スナップショッ

ト用デバイスを介してスナップショットをマウントし読み

出せ、スナップショットを解放できる

制約条件

アンマウントやシステムクラッシュによりスナップショットは消

滅する

ディスクフル時はスナップショット取得元

FSがReadOnlyへ移

行する

ディスクフルに関与しない部分への読み出しはスナップショット・取得

FS共に可能

(37)

現時点で実装した機能

実装済が

青色

, 未実装が

赤色

ffsスナップショットと異なる方式で実装する機能

Copy-On-Write

beforeイメージジャーナル

既存のジャーナル量を増やして

data=journalでスナップショットファイ

ルをジャーナルしたアドホックな実装

スナップショットファイルの

delayed allocation

クラッシュリカバリ

ffsスナップショットと同じ考え方で実装する機能

スナップショット初期化

(スナップショットファイル作成)

ブロック解放抑止

スナップショット用デバイス

(38)

ext3スナップショット

現時点の実装の評価

(39)

評価観点と測定内容

評価観点

LVMスナップショット(ext3 on LVM)との比較

スナップショット未取得時のデータ更新・新規作成の速さ

スナップショットを取得する速さ

スナップショット取得後のデータ更新の速さ

スナップショット取得後のデータ新規作成の速さ

ext3スナップショットではCopy-On-Write処理が発生しないが、LVMス

ナップショットでは

Copy-On-Write処理が発生する

測定内容

(3回測定した各平均時間)

スナップショット未取得時のデータ更新・新規作成の時間

スナップショット取得の時間とその際の

FS停止の時間

スナップショット取得後の既存ファイルのデータ更新の時間

スナップショット取得後の新規ファイルのデータ作成の時間

(40)

2005/06/01

Linux Conference 2005

39

既存データ更新と新規データ作成の時間

•データの更新・新規作成ともに若干遅い

•Copy-On-Writeのために予約するジャーナル量が増え、ジャー

ナルのディスク書き出し動作が増えているため

既存データ更新時間

新規データ作成時間

既存データ更新時間

(スナップショット未取得時)

0

50

100

150

200

250

300

350

200MB x 2 / 1GB

1GB x 2 / 20GB

既存データ更新容量 / 取得元FS容量

se

c

ext3ss

LVMss

新規データ作成時間

(スナップショット未取得時)

0

50

100

150

200

250

300

350

200MB x 2 / 1GB

1GB x 2 / 20GB

新規データ作成容量 / 取得元FS容量

se

c

ext3ss

LVMss

(41)

スナップショット取得の時間

スナップショット取得時間

ddコマンドで新規データ作成しながら

スナップショットを取得

スナップショット取得時間(I/O負荷無)

0

0.5

1

1.5

2

2.5

3

3.5

4

4.5

5

1GB

20GB

スナップショット取得元FS容量

se

c

ext3ss

LVMss

スナップショット取得時間(I/O負荷有)

0

20

40

60

80

100

120

140

160

1GB

20GB

スナップショット取得元FS容量

se

c

ext3ss

LVMss

•ext3の方が3∼4倍程度遅い

•メタデータのコピー処理で必要なブ

ロックを前もって確保するのではなく、

その都度ブロックを確保しているため

•両者とも数十秒以上掛かっている

•LVMはI/O高負荷時スナップショット

取得が遅いためか

ddコマンドによる

データの作成が速いためか

(42)

2005/06/01

Linux Conference 2005

41

スナップショット取得時の

FS停止の時間

スナップショット取得時FS停止時間

•I/O負荷が無い時は問題無い

ddコマンドで新規データ作成しながら

スナップショットを取得

•I/O負荷が有る時は数十秒もFS停

止していて問題有り

•もしくは やむを得ない(かも)

FS停止時間(I/O負荷有)

0

5

10

15

20

25

30

35

40

45

1GB

20GB

スナップショット取得元FS容量

se

c

ext3ss

FS停止時間(I/O負荷無)

0

0.5

1

1.5

2

2.5

3

3.5

4

4.5

5

1GB

20GB

スナップショット取得元FS容量

se

c

ext3ss

(43)

既存データ更新と新規データ作成の時間

既存データ更新時間

新規データ作成時間

新規データ作成時間

(スナップショット取得時)

0

200

400

600

800

1000

1200

1400

200MB x 2 / 1GB

1GB x 2 / 20GB

新規データ作成容量 / 取得元FS容量

se

c

ext3ss

LVMss

既存データ更新時間

(スナップショット取得時)

0

200

400

600

800

1000

1200

1400

200MB x 2 / 1GB

1GB x 2 / 20GB

既存データ更新容量 / 取得元FS容量

se

c

ext3ss

LVMss

•ext3の方が1.5∼4倍程度遅い

•LVMの方がCopy-On-Write単

位が大きいため、効率が良い

•少し遅すぎる(かも)

•ext3の方が1.5倍∼3倍程度速い

•LVMの方がCopy-On-Write単

位が大きいため、余分なCopy-On-Writeが発生している

(44)

2005/06/01

Linux Conference 2005

43

現時点の実装の評価のまとめ

(LVMとの比較)

利点

スナップショット取得後の新規データ作成が速い

更新されないデータは

Copy-On-Writeされないので、余

分なディスク容量の消費が無い

欠点

(=今後の課題)

スナップショット取得後の既存データ更新が遅い

スナップショット取得時間や

I/O高負荷下のFS停止が長

•課題はあるもののFSレイヤで実装する事により、

LVMスナップショットと異なる性能特性を示し、ext3

スナップショットの存在意義が認められる

•ただし実装途中なので数値は参考程度に

(45)

ext3スナップショット

デモ

(46)

2005/06/01

Linux Conference 2005

45

ext3スナップショットの利用の流れ

利用例

スナップショットの取得から利用まで

スナップショットの利用終了から解放まで

# e3snapconfig

–c /mnt/src/snapshot.img

# ssdevconfig

–c /mnt/src/snapshot.img /dev/ssdev/0 …

# mount /dev/ssdev/0 /mnt/ss

# cd /mnt/ss

# umount /mnt/ss

# ssdevconfig

–d /dev/ssdev/0

# e3snapconfig

–d /mnt/src/snapshot.img

(47)
(48)

2005/06/01

Linux Conference 2005

47

まとめ

ext3FSへのスナップショット機能追加の設計と実装

について述べ、その存在意義を示した

現時点のソースコード及び利用手順を以下で公開して

いる

http://sourceforge.net/projects/ext3snapshot/

今後の課題

スナップショット取得の性能向上

未実装部分の実装

スナップショットの永続化

beforeイメージジャーナルの実装

クラッシュリカバリの実装

複数のスナップショットの取得

スナップショットファイルの

delayed allocationの実装

(49)

ご静聴頂きまして

誠にありがとうございました

前野真輝′ 松尾隆利′ 山幡為佐久″

参照

関連したドキュメント

チューリング機械の原論文 [14]

施工計画書 1)工事概要 2)計画工程表 3)現場組織表 4)主要機械 5)主要資材 6)施工方法 7)施工管理計画. 8)緊急時の体制及び対応

概要/⑥主要穀物の生産量.

本文書の目的は、 Allbirds の製品におけるカーボンフットプリントの計算方法、前提条件、デー タソース、および今後の改善点の概要を提供し、より詳細な情報を共有することです。

建設機械器具等を保持するための費用その他の工事

実験の概要(100字程度)

第四次総合特別事業計画の概要.

ALPS 処理水の海洋放出に 必要な設備等の設計及び運 用は、関係者の方々のご意 見等を伺いつつ、政府方針