JP2014524610A - トークン・ベースのファイル動作 - Google Patents

Abstract

トークン・ベース・ファイル動作を可能にする実施形態について記載する。クライアントは、ファイル・アクセス・プロトコルにしたがってフォーマットされた特殊なオフロード・ファイル動作を要求することができる。このファイル動作は、オフロード・リード動作でもオフロード・ライト動作でもよい。オフロード・リード動作では、クライアントは、格納されているファイルからデーターまたはその一部を論理的に読み出すことを要求する。応答して、ファイル・サーバーは、論理的に読み出されたデーターを表すトークンを含む応答を供給する。実施形態の中には、何らかの理由でデーターの全てを表すトークンを供給することができない場合、ファイル・サーバーが要求されたデーターの全て未満を表すトークンと共に応答を戻す場合もある。次いで、トークンは、後続のオフロード・ライト動作において、クライアントによって使用することができる。実施形態では、トークンは、サーバーおよびクライアントに跨がって安全にそして確実に使用することができる不変のデーターを表す。
【選択図】図１

Description

従来技術

[0001] 大量のデーターをコピーする従前の方法では、データーはソース・ファイルからローカルＲＡＭに読み込まれ、次いで同じバイトがＲＡＭから逆に宛先ファイルに書き込まれる。

このプロセスでは、コピーの完了にはデーターがローカルＲＡＭに入ることさえも本質的に必要でない場合でも、データーがローカルＲＡＭを含む経路を進むことが必要になる。最終的なソースと最終的な宛先との間でデーターが辿ることができる経路があり、この経路が信頼があってこちらの方が速い場合、ローカルＲＡＭを通る回り道は不要になる。この問題は、信頼があってより速い経路とローカルＲＡＭ経由の経路との間における速度差が大きいと一層深刻になる。現在、サーバー・メッセージ・ブロック（ＳＭＢ）ファイル・サーバーのような、一部のファイル・サーバーは、ソース・ファイルの範囲を宛先ファイルの範囲にコピーすることを、クライアントに許可している。しかしながら、同じファイル・サーバーにおいて開いているファイル間でデーターをコピーするときの限度というような、複数の制限がある。また、ＳＭＢファイル・サーバーは、ソースおよび宛先範囲双方を指定する１つのコマンドを発行することしか、クライアントに許可しない。多くの場合、コピーを行うにはリードおよびライトを別々に使用するようにクライアント・コード構造が設定されるが、ＳＭＢファイル・サーバーがデーターの範囲をコピーするために設ける現在の方法とは調和しない。

[0002] 実施形態が作られたのは、これらおよびその他の考察に関してである。また、比較的具体的な問題について説明したが、実施形態は、背景において特定した具体的な問題を解決することに限定されるのではないことは言うまでもない。

[0003] この摘要は、詳細な説明において以下で更に説明する概念から選択したものを、簡略化した形態で紹介するために設けられている。この摘要は、特許請求する主題の主要な特徴や必須の特徴を特定することを意図するのではなく、特許請求する主題の範囲を判断するときに補助として用いられることを意図するのでもない。

[0004] トーク・ベースのファイル動作を可能にする実施形態について記載する。この実施形態は、クライアントがファイル・サーバーとのセッションを作ることを考慮に入れている。セッションは、任意のファイル・アクセス・プロトコルを使用して作ることができ、一例にはサーバー・メッセージ・ブロック（ＳＭＢ）プロトコルが含まれる。セッションが作られた後、クライアントはこのファイル・アクセス・プロトコルにしたがってフォーマットされた特殊なオフロード・ファイル動作を要求することができる。このファイル動作は、リード動作でもライト動作でもよい。オフロード・リード動作では、クライアントは、ファイル・サーバーにアクセス可能なファイル記憶システムに格納されているファイルからファイル・データーを読み出すことを要求する。その代わりに、ファイル・サーバーは、そのデーター・ファイルを表すトークンを含む応答を供給する。実施形態の中には、何らかの理由でファイル・データーの全てを表すトークンを供給することができない場合、ファイル・サーバーがファイル・データーの全て未満を表すトークンと共に応答を戻す場合もある。次いで、トークンは、後続のオフロード・ライト動作、または他の関連動作（例えば、必要になった場合、後にトークンによって表されるデーターを得る）において、クライアントによって使用することができる。実施形態では、トークンは、サーバーおよびクライアントに跨がって安全にそして確実に使用することができる不変のデーターを表す。

[0005] 実施形態は、コンピューター・プロセス、計算システム、あるいはコンピューター・プログラム製品またはコンピューター読み取り可能媒体のような製造品目として実現することができる。コンピューター・プログラム製品は、コンピューター・システムによって読み取ることができ、コンピューター・プロセスを実行するための命令のコンピューター・プログラムをエンコードしたコンピューター記憶媒体とすることができる。また、コンピューター・プログラム製品は、計算システムによって読み取り可能であり、コンピューター・プロセスを実行するための命令のコンピューター・プログラムをエンコードした、搬送波上の伝搬信号であることもできる。

[0006] 以下の図を参照して、非限定的かつ非網羅的な実施形態について説明する。
図１は、実施形態を実現するために使用することができるシステムを示す。 図２は、実施形態にしたがって、ファイル・アクセス・プロトコルを使用するトークン・ベース・ファイル動作に関与するクライアントおよびサーバーのブロック図を示す。 図３は、実施形態にしたがって、オフロード・ファイル動作を処理する動作フローを示す。 図４は、実施形態にしたがってオフロード・リード要求を処理する動作フローを示す。 図５は、実施形態にしたがってオフロード・ライト要求を処理する動作フローを示す。 図６は、実施形態にしたがってオフロード・ファイル動作を要求する動作フローを示す。 図７は、実施形態を実現するのに適した計算環境のブロック図である。

[0014] 添付図面を参照して種々の実施形態について更に詳しく説明する。添付図面は、本明細書の一部をなし、具体的な実施形態例を示す。しかしながら、実施形態は、多くの異なる形態でも実現することができ、本明細書において示される実施形態に限定されるように解釈してはならない。むしろ、本開示が周到で完全であり、実施形態の範囲を全て当業者に伝えるように、これらの実施形態が提示されるのである。実施形態は、方法、システム、またはデバイスとして実施することもできる。したがって、実施形態は、ハードウェアの実現例、全体的にソフトウェアの実現例、またはソフトウェアおよびハードウェアの形態を組み合わせた実現例という形態をなすことができる。以下の詳細な説明は、したがって、限定的な意味で捕らえてはならない。

[0015] 図１は、実施形態を実現するために使用することができるシステム１００を示す。システム１００は、クライアント１０２および１０４ならびにサーバー１０６を含む。クライアント１０２および１０４は、ネットワーク１０８を介して、サーバー１０６と通信する。サーバー１０６は、クライアント１０２および１０４におけるアプリケーションによってアクセスされる情報を格納する。クライアント１０２および１０４は、クライアント１０２および１０４における情報にアクセスするために、サーバー１０６とのセッションを作る。図１ではサーバー１０６と通信するものとしてクライアント１０２および１０４のみが示されているが、他の実施形態では、２つよりも多いクライアントがサーバー１０６からの情報にアクセスすることもできる。

[0016] 実施形態では、クライアント１０２および１０４におけるアプリケーションが、アプリケーションに対して透過的なファイル・システムに、ファイル情報を要求する。ファイル情報は、サーバー１０６におけるファイル・システムから引き出される。一実施形態では、サーバー１０６におけるこのようなファイル・システムは、リモート・ファイル・システムである。他の実施形態では、サーバー１０６におけるファイル・システムは分散型ファイル・システムである。本明細書において開示する実施形態にしたがって、本開示の主旨および範囲から逸脱することなく、複数のタイプのファイル・システムを使用することができる。更に、図示されていないが、実施形態の中には、１つのサーバー１０６の代わりに、サーバーが、例えば、サーバー・クラスターの一部である複数のサーバーの内の１つであってもよい場合もある。他の実施形態では、サーバーは、サーバー・クラスターの一部ではない複数のサーバーの内の１つでもよい。このような実施形態における複数のファイル・サーバーは、クライアント１０２および１０４に対して、冗長性および情報、例えば、ファイル情報の高い可用性を提供する。

[0017] 一実施形態では、クライアント１０２および１０４は、サーバー１０６におけるリモート・ファイル・システムに格納されているファイルに対して実行される複数のファイル動作を送ることができる。クライアント１０２および１０４は、ファイルに対して実行されるファイル動作の要求をフォーマットするために、ファイル・アクセス・プロトコルを使用する。このファイル・アクセス・プロトコルは、ネットワーク・ファイル・システム（ＮＦＳ）、またはサーバー・メッセージ・ブロック（ＳＭＢ）プロトコルの一バージョンというような、任意のしかるべきプロトコルであればよい。実施形態によれば、クライアントは、正規のリードおよびライト・ファイル動作を送ることに加えて、オフロード・リード動作およびオフロード・ライト動作も要求することができる。これらは、トークン・ベース動作である。以下で更に詳しく説明するが、オフロード・ファイル動作は、実際のデーターをネットワークを介してクライアント１０２または１０４のいずれかにおけるローカルＲＡＭに送る(transfer)ことを必要とせずに、大量のデーターをクライアント１０２および１０４によって動かすことを可能にする。

[0018] 一実施形態を例示すると、クライアント１０２がサーバー１０６とのセッションを作る要求を送ることができる。例えば、クライアント１０２は、サーバー・メッセージ・ブロック（ＳＭＢ）プロトコルの一バージョンを使用して、サーバー１０６に格納されているファイル・システムにアクセスするために、サーバー１０６とのセッションを作ることができる。セッションを作るには、クライアント１０２とサーバー１０６との間において送信される複数のネゴシエート要求および応答の交換が必要になる場合がある。ＳＭＢプロトコルのバージョンでは、具体的に定められたネゴシエート・パケットがあり、これらを使用して、セッションの間に使用されるプロトコルの正確なバージョンをネゴシエートし、更にクライアント、例えば、１０２およびサーバー、例えば、１０６の双方の能力を互いに通知する(advertise)。一実施形態では、ネゴシエート・パケットは、サーバー１０６がトークン・ベース・ファイル動作、即ち、オフロード・リードおよびオフロード・ライト・コマンドを扱うことができることの指示を含むこともできる。これによって、クライアントは、所望であれば、オフロード・ファイル動作をサーバーに要求してもよいことを知ることができる。

[0019] 以上の例を続けると、セッションが作られた後、クライアント１０２は、サーバー１０６におけるファイル・システムにおいてファイルを開くために、ＳＭＢプロトコルにしたがってフォーマットされたメッセージを送ることができる。サーバーは、ファイル開放のためのハンドルで応答することができる。次いで、クライアント１０２は、ＳＭＢプロトコルにしたがってフォーマットされたオフロード・リード動作を要求し、ファイルからのファイル・データーを要求することができる。一実施形態では、クライアントは、オフロード・リード動作においてファイルの一部からのデーターを要求する。オフロード・リード動作要求は、トークン・ベース・リード動作である。

[0020] クライアント１０２からの要求に応答して、サーバー１０６は、ＳＭＢプロトコルにしたがってフォーマットされた応答を、クライアント１０２が要求したファイル・データーを表すトークンと共に送る。実施形態の中には、サーバー１０６が、トークンを生成し、同じファイル・データーを要求しているかもしれないクライアント１０４のような、他のクライアントからの任意の要求にわたって、トークンがファイル・データーを一貫して表すことを保証する役割を担うことができる場合もある。他の実施形態では、ファイル・サーバーはクライアントからの任意の要求を、基礎ファイル記憶システムに渡すのでもよい。これらの実施形態では、基礎ファイル記憶システムが、クライアント１０２によって要求されたファイル・データーを表すトークンを生成する役割を担う。いずれの実施形態でも、サーバー１０６は、クライアント１０２に対する応答をトークンと共に送る。トークンを生成するとき、実施形態は、例えば、トークンを作るために使用されるソース・ファイルの範囲が連続的でない場合でも、トークンが作られてもよいことを考慮に入れている。このような実施形態では、このようなソース範囲からのデーターは、論理的に繋がれ、トークンによって表される１つの論理範囲のデーターとなる。実施形態の中には、実現例が内部的にトークンを具体的なソース範囲と関連付けるとよい場合もあり、このようなソース範囲は互いに連続的でなくてもよい。

[0021] トークンは、不変のデーター、即ち、クライアント１０２が要求するファイル・データーを表す。したがって、クライアント１０２は、サーバー１０６によって戻されたトークンを使用して、他のファイル動作を実行することができる。例えば、後の時点において、クライアント１０２は、トークンを使用してデーターを他のファイルに書き込むことができる。この例では、クライアント１０２は、ＳＭＢプロトコルにしたがってフォーマットされたオフロード・ライト動作を要求することができ、このオフロード・ライト動作もトークン・ベース・ファイル動作である。このオフロード・ライト動作は、クライアント１０２に以前に供給されたトークンを含むことができる。オフロード・ライト動作は、トークンによって表されるファイル・データーを、サーバー１０６における他のファイルに書き込むことを要求することができる。この要求を受けたことに応答して、サーバー１０６は、一実施形態では、次に要求を処理して、トークンによって表されるファイル・データーをサーバー１０６における他のファイルに書き込む。他の実施形態では、要求を受けたことに応答して、サーバー１０６は最初に受信したトークンの有効性を判断し、トークンが有効である場合、次にトークンによって表されるファイル・データーを、サーバー１０６における他のファイルに書き込む。先に注記したように、トークンが基礎ファイル記憶システムまたはそれよりも下位のレイヤー（１つまたは複数）によって生成される実施形態では、サーバー１０６は単にオフロード・ライト要求を基礎ファイル記憶システムに渡すだけであり、次いで基礎ファイル記憶システムがこの要求を処理して、ファイル・データーを他のファイルに書き込む。サーバー１０６は、次に、応答をクライアント１０２に送り、オフロード・ライトが成功であったか否か示す。「ファイル」データーに言及するが、他の実施形態は、トークンが任意のタイプのデーターを表すことを考慮に入れている。例えば、実施形態は、トークンが、ファイル、ボリューム、ディスク、ボリューム・スナップショット、ディスク・スナップショット、ブロブ・ストア等のような、任意の記憶コンテナから得られたものであることを考慮に入れている。「ファイル・データー」という用語は、本明細書では、例示の目的に限って使用されているのであり、限定を意図するのではない。更に、以上で説明した実施形態は、オフロード・ライト動作が、トークンによって表されるファイル・データーをサーバー１０６における他のファイルに書き込むことを要求することを考慮に入れているが、他の実施形態は、オフロード・ライト動作が、トークンによって表されるファイル・データーの一部をサーバー１０６における他のファイルに書き込むことを要求することを考慮に入れている。

[0022] 加えて、以上で説明した実施形態は、オフロード・ライト動作が、以前にクライアント１０２に供給されたトークンを含むことを考慮に入れているが、他の実施形態は、クライアント１０２が、周知のトークンを、オフロード・ライト動作でのトークンとして使用することを考慮に入れている。例えば、ゼロ・トークンのような周知のトークンが、以前の対応するオフロード・リードが全くなくても、データー（ゼロのような）を書き込むために使用されてもよい。

[0023] 実施形態の中には、ファイル・サーバー１０６がクライアントによって要求されたファイル・データーの全てに対してトークを作ることができない場合もある。これが起こり得るのは、例えば、クライアント１０４のような他のクライアントが、クライアント１０２が要求したファイル・データーのファイルのある部分にロックをかけた場合である。これらの実施形態では、サーバー１０６は短縮応答(truncated response)を送ることもできる。即ち、応答は、クライアント１０２が要求したファイル・データーの一部のみを表すトークンを含む。つまり、実施形態では、この応答が示すのは、トークンが、オフロード・リード要求において要求された第１データーの全て未満を表すということである。実施形態の中には、このトークンが不連続なデーター範囲を表すことができる場合もある。しかしながら、他の実施形態では、トークンは連続するデーター範囲を表すことができるが、オフロード・リード要求においてクライアント１０２が要求したファイル・データーよりも少ない場合もある。これらの実施形態では、サーバーの応答は、短縮応答において送られたトークンによって表されるファイル・データーの部分の指示を含む。

[0024] 実施形態の中には短縮オフロード・リード応答を考慮に入れているものもあるが、本開示の実施形態は短縮オフロード・ライトも考慮に入れている。先に説明したように、オフロード・ライト動作は、関連するトークンによって表されるデーターが、サーバー、例えば、サーバー１０６における他のファイルに書き込まれることを要求することができる。この要求を受けたことに応答して、サーバー１０６は次にこの要求を処理して、トークンによって表されるファイル・データーをサーバー１０６における他のファイルに書き込む。実施形態では、サーバー１０６は、トークンによって表されるデーターの全てを他のファイルに書き込むことができない。その結果、実施形態では、オフロード・ライトは短縮される場合があり、「書き込み長」は、例えば、書き込むことを要求された長さ未満になる。例えば、サイズの制約のために、トークンによって表されるデーターの全てを他のファイルに書き込む能力が制限される場合がある。他の実施形態では、ファイルの一部に書き込みのロックがかけられていると、このファイルの部分が書き込まれることが妨げられるであろう。また、処理エラー、または他のタイプのエラーも、トークンによって表されるデーターの一部が他のファイルに書き込まれない原因になり得る。更に、トークンが部分的に転化されていること、または部分的に無効であることもあり、その場合サーバー１０６はこのデーターの転化した部分／無効の部分を他のファイルに首尾良く書き込むことはできない。本明細書に開示される実施形態によれば、本開示の主旨や範囲から逸脱することなく、他の理由でも、トークンによって表されるデーターの全てが他のファイルに書き込まれることが妨げられることがある。短縮オフロード・ライトを必要とする実施形態では、短縮オフロード・ライト応答をサーバー１０６からクライアント１０２に送り、例えば、データーの一部が他のファイルに書き込まれなかったことを示すことができる。このような指示は、実施形態では、例えば、フラグまたは他のインディケーターの使用によって行うことができる。更に、実施形態では、短縮オフロード・ライト応答は、実際に書き込まれたデーター量を示す。

[0025] 以上の説明は、図１に示した実施形態がどのように動作することができるかについての一例に過ぎない。以下で更に詳しく説明するように、実施形態は異なるステップまたは動作を伴うこともできる。これらは、任意の適したソフトウェアまたはハードウェア・コンポーネントを使用して実現することができる。

[0026] これより図２に移ると、図２は、クライアント２０２、クライアント２０４、サーバー２０６、およびサーバー２０８を含むソフトウェア環境２００のブロック図を示す。また、ファイル情報が格納されるファイル・ストレージ２１０も示されている。

[0027] 図２に示すように、クライアント２０２およびクライアント２０４は、各々、ファイル情報を要求することができるアプリケーションを含む。このアプリケーションは、例えば、ワープロ・アプリケーション、表計算アプリケーション、ブラウザー・アプリケーション、またはファイルに対するアクセスを要求する任意の他のアプリケーションとすることができる。図２に示す実施形態では、ファイルは、ファイル・ストレージ２１０内部に格納されているファイル・システムに配置される。図２は、本明細書において開示する一実施形態にしたがって、サーバー２０６および２０８に共有ストレージ能力を与えるファイル・ストレージ２１０を示すが、他の実施形態は他の記憶手段を有する。例えば、サーバー２０６およびサーバー２０８は、各々、それら自体の記憶手段を有することもでき、この記憶手段は、実施形態にしたがって、着脱型(detached)でも据え付け型(attached)でもよい。更に他の実施形態では、サーバー２０６およびサーバー２０８は、各々、それら自体の記憶手段を有し、ファイル・ストレージ２１０の使用によって記憶能力を共有させることもできる。本明細書において開示する実施形態によれば、本開示の主旨および範囲から逸脱することなく、複数のタイプのストレージを使用することができる。更に、クライアント２０２およびクライアント２０４は、各々、アプリケーションからのファイル要求をファイル・サーバーにリディレクトするリディレクターも含み、ファイル・サーバーはリモート・ファイル・システムへのアクセスを与える。リディレクターは、ファイル・アクセス・プロトコルを使用して、ファイル・サーバーと通信する。実施形態の中には、ファイル・アクセス・プロトコルがＮＦＳまたはＳＭＢプロトコルの一バージョンであるとよい場合がある。例示の目的に限って、クライアント２０２およびクライアント２０４におけるリディレクターが、ＳＭＢ２のような、ＳＭＢプロトコルの一バージョンを使用してファイル・サーバーと通信することを仮定して、図２について説明する。しかしながら、実施形態はＳＭＢプロトコルの使用に限定されるのではない。

[0028] 図２では、サーバー２０６および２０８は、各々がファイル・サーバーを含むように示されている。先に注記したように、ファイル・サーバーは、クライアント２０２およびクライアント２０４におけるリディレクターと通信するために、ＳＭＢプロトコルの一バージョンを使用することができる。また、サーバー２０６および２０８の各々は、ファイル・データーを表すトークンを生成するトークン生成モジュールも含む。加えて、ファイル・ストレージ２１０も、ファイル・データーを表すトークンを生成するトークン生成モジュールを含む。

[0029] クライアントとサーバーとの間においてセッションを作るためのＳＭＢプロトコルの使用は、クライアント２０２におけるリディレクターのようなリディレクターがネゴシエート要求をサーバー２０６のようなファイル・サーバーに送ることから開始する。リディレクターおよびファイル・サーバーは、セッションに使用されるＳＭＢのバージョンをネゴシエートするために、ネゴシエート・パケットを交換する。加えて、このネゴシエーションの間に、能力(capabilities)も交換することができる。一実施形態では、サーバー２０６は、ファイル・サーバーからクライアントに送られるネゴシエート応答パケット内に能力フラグを含み、ファイル・サーバーがオフロード・ファイル動作の使用をサポートすることを、クライアントに示すことができる。他の実施形態では、クライアント２０２およびサーバー２０６は、単にＳＭＢプロトコルのバージョンをネゴシエートすることもでき、このとき、当該バージョンがオフロード・ファイル動作の使用に対するサポートを含むことを理解している。更に他の実施形態では、オフロード・ファイル動作が試されるときに、プロトコルの一バージョンがオフロード・ファイル動作をサポートするという判断が行われる。例えば、クライアント２０２がオフロード・リード（またはオフロード・ライト）動作を要求するとしてもよい。サーバー２０６がオフロード・ファイル動作をサポートする場合、サーバー２０６はこの要求の処理を進める。サーバー２０６がオフロード・ファイル動作をサポートしない場合、サーバー２０６は、要求されたオフロード・ファイル動作を実行できないことを示す応答をクライアント２０２に送る。例えば、一実施形態では、サーバー２０６がオフロード・ファイル動作をサポートしない場合、サーバー２０６は、エラー・メッセージおよび／またはこれを示すフラグでクライアント２０２に応答する。

[0030] 一旦ネゴシエーションが完了すると、クライアント２０２におけるリディレクターおよびファイル・サーバー２０６はセッションを作る。クライアント・リディレクターは、次いで、ファイル・アクセス要求をファイル・サーバーに送ることができる。一実施形態では、クライアント２０２におけるリディレクターは、ファイルにおいて開放を要求する。サーバー２０６は、この開放に対するハンドルを含む応答を供給する。次いで、クライアント２０２は、このハンドルを使用して、オフロード・リード動作を要求することができる。実施形態では、オフロード・リード動作は、ＳＭＢプロトコルにしたがってフォーマットされる。実施形態の中には、オフロード・リードおよびオフロード・ライト動作が、ＳＭＢプロトコル接続を使用して送られることもあり、他のファイル・システム制御コマンド（ＦＳＣＴＬ）と同様に、コマンドをＳＭＢ２入力／出力制御（ＩＯＣＴＬ）要求内にカプセル化する。以下に、実施形態においてオフロード・リード動作を要求するために使用することができる構造の一例を示す。

[0031] 先に示したように、オフロード・リード動作を要求するためにクライアントによって使用される構造は、複数のフィールドを含むことができる。実施形態では、サーバーに対する存続時間(time to live)示唆(suggestion)を含むことができる。言い換えると、このフィールドは、サーバーが送るトークンに対して示唆される寿命を示すことができる。また、この構造は、クライアントが要求するファイル・データーのファイル・オフセットおよびコピー長も含む。

[0032] この要求に応答して、サーバー２０６は応答を返送する。以下に、オフロード・リード動作に対して応答するために使用することができる構造の一例を示す。

[0033] 先に示したように、この応答は、実施形態では、クライアント２０２が要求したファイル・データーを表すトークンを含む。また、このトークンは、実施形態では、当該トークンによって表されるファイル・データーの長さも含む。

[0034] 実施形態の中には、サーバー２０６が、オフロード・リード要求に対して、失敗、即ち、このリード要求が十分に処理されなかったことの指示で応答することができる場合がある。以下に、追加情報をクライアントに示すためにオフロード・リード応答においてサーバーによって設定することができる３つのフラグを示す。

[0035] 以上に示す２番目のフラグは、ファイルが小さすぎたために要求が失敗したことを示す。小さなファイルに対するファイル・データー・ペイロードが、別個のクラスターに格納されるのではなく、直接ファイル・レコードに格納されるという状況がある可能性がある。このようなファイルに対しては、対応する小さなオフロード・リードから得られる効率は殆どないので、このようなファイルに対する小さなオフロード・リードを扱うのではなく、ソース・ファイル・システムは、オフロード・リードをやり過ごす(fail)ことができ、応答は、先に定められた２番目のフラグを含むことができる。このフラグは、ファイル・データーが小さすぎるために要求が失敗したことを示す。先に定められた最初のフラグは、オフロード・リード応答によって示される転送長(transfer length)を超える残りのデーターは、全てゼロを含むことを示す。最後に、３番目のフラグは、サーバーが、オフロード・リード要求によって示される転送長を超えるオフロード・リード要求は成功しないと判断した状況において使用することができる。３番目のフラグは、クライアントが要求するデーターの内、現在のオフロード・リード応答によって示される範囲を超える分に対して、サーバーがトークンを供給できないことを示す。図示されてないが、オフロード・リード応答は、戻される一部(sub-portion)が不連続データー（単にオフセット０からの連続バイト・カウントの代わりに）を表すことの指示というような、情報を提供することもできる。実施形態では、オフロード・リード要求は、オフロード・リードが成功することができる次の後続ソース・オフセットに関するヒントも含むことができる。以上で示した３つのフラグは当該フラグに対して数値を含むが、これらの数値は例示の目的に限って提供されたに過ぎない。他の数値または一般的な値も、実施形態にしたがって、本開示の主旨および範囲から逸脱することなく、使用することができる。

[0036] 一旦クライアント２０２が、以前のオフロード・リード要求によってまたは何らかの他の手段によって、トークンを受信したなら、クライアント２０２は、オフロード・ライト要求をサーバー２０６に発行することができる。以下に、実施形態においてクライアントがオフロード・ライト要求を送るために使用することができる構造の一例を示す。

[0037] 以上の例において示したように、オフロード・ライトの構造は、コピーする宛先ファイルのオフセット、コピーするデーターの長さ、およびトークンによって表される、データー内においてコピーを開始するオフセットを含む。また、トークンも含まれ、サーバーまたは他の手段によって受信されたのでもよい。

[0038] オフロード・ライト要求に応答して、サーバー２０６はオフロード・ライト要求を発行する。オフロード・ライト応答においてサーバー２０６によって使用されるための構造の一例を以下に示す。

[0039] 実施形態の中には、サーバー２０６がオフロード・ライト要求に失敗で応答することができる場合もある。例えば、オフロード・ライト動作が失敗する可能性があるのは、要求されたファイルが小さいファイルである、例えば、定められたサイズ閾値未満であるときである。以下に、ファイル情報が小さすぎたために要求が失敗したことを示すために、オフロード・ライト応答においてサーバーによって設定することができるフラグの例を示す。先に注記したように、小さいファイルは、大きいファイルとは異なる方法でそのデーターを格納する場合があり、このような小さなファイルに対して発行されたオフロード要求は、やり過ごす方が適していることもあり得る。何故なら、実際のファイル・データーの代わりにトークンを使用することから殆ど効率が得られないからである。他の実施形態では、オフロード・ライト動作が失敗する可能性があるのは、オフロード・ライトの受信先とデーター・ソースとの間におけるリンクが遅いときである。このような実施形態では、ファイル・システムは、オフロード・ライト動作に応答するか否か決定するときに、リンク・ステータス・チェックを実行することができる。このような事例では、サーバー２０６はオフロード・ライト要求をやり過ごすことができる。更に他の実施形態では、サーバー２０６は、トークンが無効であることから、要求をやり過ごすこともできる。例えば、トークンが期限切れである場合、これは無効であろう。無効／期限切れのトークンのためにサーバーが要求をやり過ごす場合、サーバー２０６は、オフロード・ライト要求に対して失敗で応答することができ、この場合、例えば、トークンが無効または期限切れであったために要求が失敗したことを示すために、オフロード・ライト応答においてサーバーによってフラグ（フラグ例として以下で示すような）を設定することができる。このタイプのフラグは、このライト動作の単なる再試行はうまくいかないこと、そして新たなトークンを生成するためには読み出しし直さなければならないことのヒントとして、クライアントに対して作用することができる（即ち、失敗は、リンクの一時的な遅さによるのではなく、例えば、トークンが無効であったためである）。代替実施形態では、所与のトークンがもはや有効でないことを示すために、具体的なステータスを戻すこともできる。つまり、実施形態は、トークンがもはや有効でないことを示すために、リターン・ステータスを使用することを考慮に入れており、一方他の実施形態は、このような指示を与えるためにフラグを使用することを考慮に入れている。更に他の実施形態は、このような指示を与えるために、フラグおよびリターン・ステータスの双方を使用することを考慮に入れている。例えば、トークンの期限切れによる短縮(truncations)のときに、エラー・コードの代わりに、同じトークン（１つまたは複数）を使用してオフロード・ライトの残りを再試行しても無駄であることを示すために、フラグ、例えば、OFFLOAD_WRITE_FLAG_TOKEN_INVALIDと共に、短縮値を含む成功を、FSCTLのコーラーに戻す動作を行うことができる。本開示の主旨および範囲から逸脱することなく、本明細書において開示する実施形態によれば、複数の他のタイプの条件のために、オフロード・ライトの失敗に至ることもある。

[0040] 以上で示したフラグは、当該フラグに対する数値を含むが、これらの数値は例示の目的に限って提供されたに過ぎない。他の数値または一般的な値も、実施形態にしたがって、本開示の主旨および範囲から逸脱することなく、使用することができる。

[0041] 更に、実施形態の中には、先に説明したように、オフロード・ライトが短縮されることを考慮に入れているものもあり、この場合、書き込み長は、例えば、書き込みを要求された長さよりも短い。このような実施形態では、サーバーは、短縮オフロード・ライト応答で、オフロード・ライト要求に応答し、書き込むことが要求されたデーターの一部だけが実際に書き込まれたことを示す。

[0042] 実施形態では、オフロード・リードおよびライト動作において使用されるトークンは、ある規格にしたがってフォーマットされる。例えば、小型コンピューター・システム・インターフェース（ＳＣＳＩ）規格は、一実施形態にしたがって、使用することができるトークン・フォーマットの定義を提供することができる。とりわけ、高速コンピューター・インターフェース仕様および／または規格を含む複数のタイプの規格も、本明細書において開示する実施形態にしたがって、本開示の主旨および範囲から逸脱することなく使用することができる。ＳＣＳＩ規格は一例として示したに過ぎない。標準的なフォーマットの使用により、異なるデーター・アクセス・プロトコルを使用する他のサーバーとトークンを相互動作可能にすることができる。

[0043] 実施形態では、サーバー２０６は、以前にオフロード・リードが（サーバーからまたは任意のソースから）なかった場合でも、オフロード・ライト・コマンドに指定された周知のトークン値を認識し使用することができる。例えば、サーバー２０６は、ゼロを含む範囲を表す周知のトークンを戻すことができる。クライアント２０２は、これを、ソース・ファイルの基礎範囲がゼロであること、そしてこのトークンに関連するデーターが全てゼロであることを示すものとして解釈する。他の実施形態では、正常に読み取られたときにファイル・システムがゼロを戻す場合のように、オフロード・リード要求に応答して、ゼロ・トークンを戻すこともできる。このような状況が発生する可能性があるのは、例えば、ファイルの疎な範囲が読み取られる場合である。更に他の実施形態では、サーバー２０６は、割り当てを取り消されたトークンのような、他の周知のトークンも受け入れることができる。

[0044] サーバーにおいてトークンを生成するためにトークン・ジェネレーターを使用する実施形態では、オフロード・リード要求から戻されるトークンは、情報をサーバー２０６に要求する任意のクライアントによって使用可能である。つまり、クライアント２０４はクライアント２０２からトークンを受信するのでもよく、そしてオフロード・ライト動作をサーバー２０６に要求するためにこのトークンを使用することができる。クライアント間でトークンが渡される実施形態では、クライアントはそれらが選択した任意のプロトコルまたはトランスポートによってこのようなトークンを渡すことができる。クライアント間でトークンを渡すモードは、トークン自体には関係ない。したがって、トークンはサーバー２０６との異なる接続に跨がって使用可能であり、これらの接続は異なるクライアントによって作ることができる。このように、サーバー２０６は、ファイル・ストレージ２１０がオフロード・リードおよびライト動作をサポートするか否かには関係なく、オフロード・リード要求および一部のオフロード・ライト要求にサービスする(service)ことができる。オフロード・ライトにおいてサーバー２０６に供給されるトークンは、クライアントが現在開いているハンドルを有するファイルから得られたものである必要はなく、更にクライアントがアクセスすることができるファイルから得られたものである必要もない。クライアントは、少なくともトークンが得られた時点においてそのトークンが得られたファイル（１つまたは複数）にアクセスすることができる他のクライアントを介して間接的にトークンを得ることもできる。１つの接続を介して１つの共有(share)、たとえば、ファイル共有から読み取られたオフロード・リードによってクライアントによって得られたトークンは、クライアントによって異なる共有または異なる接続に対して発行されたオフロード・ライトにおいて、首尾良く使用することができる。

[0045] 実施形態では、トークンは複数のサーバーに跨がって使用可能であるとよい。即ち、トークンは、本来そのトークンが発生したサーバーでなくても、そのサーバーにおいて使用されてもよい。言い換えると、トークンがサーバー２０６、サーバー２０８、またはファイル・ストレージ２１０において生成されるとき、このようなトークンは、そのトークンを受け入れることを決定した任意のサーバーにおいて使用することができる。例えば、先の実施形態では、クライアント２０２によって送られたオフロード・リード要求がファイル・ストレージ２１０に渡されるのでもよく、ファイル・ストレージ２１０は、このオフロード・リード要求に対してトークンを生成する。後の時点において、クライアント２０２がサーバー２０８に接続した場合、サーバー２０６へのその接続によって既に供給されているトークンを使用して、オフロード・ライト動作のような他の動作を実行することができる。この例では、サーバー２０８は任意のオフロード・ライト動作を、元来このトークンを作ったファイル・ストレージ２１０に渡す。このように、トークンは、複数のサーバーに跨がって使用可能にすることができる。この実施形態は、例えば、共有ストレージを使用するサーバー・クラスターがファイル・サービスをクライアントに提供するために使用される状況において使用することができる。

[0046] 認めることができるであろうが、環境２００についての以上の説明は、本明細書において説明する実施形態を限定することは意図していない。図２およびその説明は、単に一部の実施形態の実現例を例示することを意図するに過ぎない。他の実施形態では、オフロード動作が１つ以上のファイルおよび１つ以上のトークンを伴ってもよい。つまり、実施形態は、図２において示され説明されたものには限定されない。例えば、オフロード・リードが、１つのファイルまたは複数のファイルの複数のセグメントを、１つのトークンまたは複数のトークンを含むオフロード・リード応答によって読み取ることを考慮に入れてもよい。同様に、実施形態の中には、オフロード・ライト動作が、１つ以上のファイルに関連する１つ以上のトークンを識別できる場合もある。

[0047] 図３、図４、図５、および図６は、実施形態による動作フロー３００および４００を示す。動作フロー３００および４００は、任意の適した計算環境において実行することができる。例えば、これらの動作フローは、図１および図２に示したようなシステムおよび環境によって実行することができる。したがって、動作フロー３００および４００の説明は、図１および図２のコンポーネントの内少なくとも１つに言及することもある。しかしながら、このような図１および図２のコンポーネントに対する言及はいずれも、説明のために過ぎず、図１および図２の実現例は、動作フロー３００および４００の非限定的な環境であることは理解されてしかるべきである。

[0048] 更に、動作フロー３００および４００は、特定の順序で順次図示および説明されるが、他の実施形態では、これらの動作は異なる順序で、複数回、および／または並列に実行することもできる。更に、実施形態によっては、１つ以上の動作を省略すること、または組み合わせることもできる。

[0049] 実施形態では、図３に示すフロー３００は、少なくとも部分的に、サーバー、例えば、サーバー２０６（図２）において実行しているファイル・サーバーによって実行することができる。フロー３００は、動作３０２において開始し、ファイル・サーバーへの接続要求が受け取られる。動作３０２において受け取られる要求は、ファイル・サーバーを介してアクセス可能なリモート・ファイル・システムに格納されているファイル情報にアクセスするために、ファイル・サーバーとのセッションを作る要求である。この要求は、クライアント、例えば、クライアント２０２および２０４（図２）によって送ることができる。動作３０２の後、フロー３００は動作３０４に移り、セッションが作られたことを示す応答が送られる。実施形態の中には、動作３０２および３０４において送られる要求および応答が、クライアントとサーバーとの間でセッションをネゴシエートするために交換される複数のメッセージの内一部であってもよい場合がある。メッセージの交換は、オフロード・ファイル動作にサービスするフィル・サーバーの能力を含む、能力の交換を含むことができる。

[0050] 動作フロー３００は動作３０４から動作３０６に移り、ファイルを開く第２要求が受け取られる。この要求は、ファイル内部の情報にアクセスするために、クライアントによって送られる。動作３０６から、フローは動作３０８に移り、応答がクライアントに送られ、ファイルへのアクセスを付与する。この応答は、応答においてファイル・サーバーによって供給されるファイル識別子を含むことができる。

[0051] 次いで、フロー３００は動作３１０に移り、オフロード動作の要求が受け取られる。このオフロード動作は、トークンによって表されるファイル・データーを要求するオフロード・リード動作、または宛先ファイルに書き込まれるファイル・データーを表すトークンを含むオフロード・ライト動作であってもよい。この動作がオフロード・リード動作である場合、フローはＡに移り、図４に続く。

[0052] 図４に示すように、フロー３００は判断３１２に移り、オフロード・リード動作において要求されるデーターを全てトークンによって表すことができるか否か判定を行う。この判断３１２は、実施形態では、複数の異なる判定を伴うことができる。例えば、オフロード・リード動作において要求されたデーターの任意の部分が、他のクライアントによる排他的使用のためにロックされているか否かについて、判定を行うことができる。これらの状況では、サーバーが、要求されたデーターの全てを表すトークンを供給することができない場合もある。判断３１２において、要求されたデーターの全てを１つのトークンによって表すことは不可能であるという判定が行われた場合、フローはＮＯを通って動作３１４に移り、トークンを含む短縮応答が送られる。この短縮応答は、応答において供給されているトークンが、オフロード・リード要求において要求されたデーターの全てを表すのではないことを示す。また、この応答は、応答におけるトークンによって表されるデーターの範囲も示すことができる。動作３１４の後、フローは３１６において終了する。

[0053] 判断３１２において、要求されたデーターの全てが１つのトークンによって表すことができるという判定が行われた場合、動作３１８において、オフロード・リード要求において要求されたファイル・データーの全てを表すトークンを含む応答が送られる。次いで、フロー３００は３１６において終了する。

[0054] 実施形態の中には、サーバーがトークンの供給元でなくてもよい場合もある。これらの実施形態では、破線で示す代替動作が、判断３１２、動作３１４、および／または動作３１８の代わりに実行されるとよい。破線で示す動作は、トークンの生成が下位レイヤー、例えば、基礎ファイル記憶レベル（１つまたは複数）において行われる実施形態において実行される。これらの実施形態では、フロー３００は、判断３１２の代わりに、クエリー３２０に移る。クエリー３２０において、オフロード・リード動作が短縮されるか否か判定を行う。オフロード・リードが短縮される場合、例えば、要求されたデーターの長さに対する調節が行われ、プロセス３００はＹＥＳに進んで、調節または短縮３２２を行う。サーバーが全く調節を行わない場合、プロセス３００はＮＯに進んで、要求を変更しないままにしておく（３２１）。次に、プロセス３００は動作３２３に進み、オフロード・リード要求がサーバーから、ファイル記憶コンポーネントまたはトークンを生成する役割を担う他のモジュールというような、下位レイヤーに渡される。

[0055] 動作３２３の後、フロー３００はクエリー３２４に移り、ファイル・ストレージ（またはトークンを生成する役割を果たす他のコンポーネント）が短縮リード動作を実行するか否か判定を行う。短縮が行われない場合、プロセス３００はＮＯに進み下位レイヤーによって要求を処理する（３２５）。次いで、トークンを含む応答がサーバーによって受信され（３２６）、動作３２６において受信される応答は、オフロード・リード動作において要求されたファイル・データーの少なくとも一部を表すトークン（１つまたは複数）を含む。このトークンは、ファイル・ストレージによって使用される任意のしかるべきフォーマットにしたがってフォーマットすることができる。一実施形態では、トークンは、予め定められたＳＣＳＩフォーマットにしたがってフォーマットされる。次いで、一実施形態にしたがって、トークン（１つまたは複数）を含む応答は、サーバーによってクライアント３２９に送られる。他の実施形態では、トークン（１つまたは複数）を含む応答は、直接ファイル・ストレージ、または他の下位レイヤーから、例えば、クライアントに送られる。

[0056] クエリー３２４に戻り、先に説明したように、トークンを生成する役割を果たすファイル・ストレージまたは他のコンポーネントが、要求されたデーターの全てを含む応答を供給するか否か判定を行う。例えば、一実施形態では、ファイル・ストレージが、オフロード・リード要求において要求されたデーターの全てを供給することができない場合もある。先に説明したように、完全な読み取りを妨げる記憶コンテナに対するロックを含む複数の理由により、短縮オフロード・リード応答になる場合があり得る。ファイル・ストレージが要求されたデーターの一部のみを供給する場合、プロセス３００はＹＥＳから動作３２７に進み、下位レイヤー、例えば、ファイル・ストレージによって要求が処理され、短縮応答が供給される。一実施形態では、次に、トークンを含む短縮応答が、クライアントに送る（３２９）ために、サーバーにおいて受信される（３２８）。他の実施形態では、トークンを含む応答は直接ファイル・ストレージまたはトークンを生成する役割を果たす他のコンポーネントからクライアントに渡される。実施形態では、受信された短縮応答３２８は、要求が１つ以上のレイヤーによって短縮されたことを示す。例えば、応答は、トークンが、オフロード・リード要求において要求されたデーターの全て未満を表すことを示す。他の実施形態では、短縮応答３２８は、要求が短縮されたことの指示を与えない。次いで、フロー３００は動作３１６において終了する。他の実施形態（図示せず）では、サーバーが、ファイル・ストレージから受信したときに、そして既にファイル・ストレージによってデーターが短縮されていると判断した場合であっても、更に応答におけるデーターを短縮することを決定することもできる。このような実施形態では、このような短縮は、動作３２６および３２８の後で、トークンを含む短縮応答をクライアント動作３２９に渡す前に行うとよい。認めることができようが、動作３２０〜３２９は、サーバーが単に下位のトークン供給元への受け渡し役として動作するときにのみ実行される。図４に示す実施形態では、トークン供給元はファイル記憶システムである。実施形態の中には、ファイル記憶システムが、次に、オフロード要求を更に下位のトークン供給元に渡す場合もある。実施形態では、任意のレイヤーが、要求を下位層に送る前または後に、短縮することができる。例えば、実施形態は、サーバーが要求を下位レイヤー、例えば、ファイル・ストレージに渡し、この下位レイヤーから応答を受信し、次いでトークン（１つまたは複数）を含む応答をクライアントに送る前に、サーバーが更に短縮を実行するか否か判定することを考慮に入れている。しかしながら、実施形態によっては、下位レイヤー（１つまたは複数）に送る前に要求を短縮する方が効率的である場合もある。先に説明したように、フロー３００は、実施形態にしたがって実行することができる動作フローの一例に過ぎない。実施形態は、図３〜図５に関して行った具体的な説明には限定されず、追加の動作を含むこともできる。例えば、図示した動作ステップは、他のステップに組み合わせること、および／または並び替えることも可能である。更に、例えば、もっと少ないステップまたはもっと多いステップを使用することもできる。

[0057] 再度図３を参照すると、動作３１０において、動作がオフロード・ライト動作である場合、フローはＢに移り、図５に続く。認めることができようが、オフロード・ライト動作は、データーを表すトークンを含む。トークンは、本開示の主旨および範囲から逸脱することなく、本明細書において開示する実施形態にしたがって、複数のタイプの記憶コンテナから得ることができる。例えば、トークンは、ファイル、ボリューム、ディスク、ボリューム・スナップショット、ディスク・スナップショット、ブロブ・ストア等から得ることができる。一実施形態では、トークンは、ソース・ファイルからこのトークンにデーターをコピーすることによって作られる。他の実施形態では、トークンは、ソース・ファイルから、トークンに関連する保持エリアにデーターをコピーすることによって、作られる。つまり、作られたトークンは、ソース・ファイルとは独立であり、論理的にデーターのそれ自体の読み取り専用コンテナとなる。図５に示すように、フローは動作３１０から動作３３０に移り、オフロード・ライト動作においてトークンに関連するデーターが特定される。

[0058] 動作３３０においてデーターが特定された後、フロー３００はクエリー３３１に移り、全ての要求データーを、例えば、サーバーによって、宛先ファイルに書き込むことができるか否か判定を行う。全ての要求データーを書き込むことができる場合、プロセス３００はＹＥＳに進み、トークンによって表されるデーターを宛先ファイル３３２に書き込む。即ち、トークンによって表されるデーターの要求された部分が、オフロード・ライト要求において要求された特定の位置に書き込まれる。成功または失敗を示す応答、そして実施形態によっては、宛先ファイルに書き込まれるデーター量が、動作３３４において、クライアントに送られる。次いで、フロー３００は３１６において終了する。一方、要求データーの全てを宛先ファイルに書き込むことができない場合、例えば、プロセス３００はＮＯに進んで、動作３３６において短縮データーを書き込む。この場合、要求されたデーターの一部が書き込まれる。要求データーの一部が書き込まれたことを示す短縮ライト応答が、次に、動作３３８においてクライアントに送られる。次いで、フロー３００は３１６において終了する。

[0059] 先に注記したように、実施形態の中には、サーバーがトークンの供給元でなくてもよい場合もある。これらの実施形態では、図５において破線で示す代替動作を、動作３３０〜３３８の代わりに実行することができる。破線の動作は、トークンの生成が下位レイヤー、例えば、ファイル記憶レベル以下で行われる実施形態において実行される。これらの実施形態では、フロー３００は、動作３３０の代わりに、クエリー３４０に移る。クエリー３４０において、下位レイヤー、例えば、基礎ファイル・ストレージに渡す前に、サーバーにおいてオフロード・ライトが短縮されるか否か判定が行われる。オフロード・ライトが短縮される場合、プロセス３００はＹＥＳに進み調節または短縮を行う（３４４）。サーバーが何の調節も行わない場合、フロー３００はＮＯに進み、オフロード・ライト要求を変更しないままにしておく（３４２）。次に、プロセス３００は動作３４６に進み、オフロード・ライト要求（トークンを含む）が、サーバーから、ファイル記憶コンポーネントまたはオフロード・ライト要求を扱う役割を担う他のモジュールのような、下位レイヤーに渡される。

[0060] オフロード・ライト要求を下位レイヤー（１つまたは複数）に渡した後（３４６）、フロー３００はクエリー３４８に進み、下位レイヤー、例えば、ファイル・ストレージが短縮ライト動作を実行するか否か判定を行う。短縮が行われない場合、プロセス３００はＮＯから動作３５０に移り、下位レイヤーがライト要求を処理する。この処理は、例えば、要求におけるトークンに関連するデーターを特定し、トークンによって表されるデーターを宛先ファイルに書き込むことを含む。下位レイヤーが短縮ライトを実行する場合、プロセス３００はＹＥＳから下位レイヤー短縮および処理動作３５２に進み、要求データーの一部が、例えば、宛先ファイルに書き込まれる。下位レイヤー（１つまたは複数）によるオフロード・ライト要求の処理に続いて、オフロード・ライト要求が、サーバーにおいて、下位レイヤーから受け取られる（３５４）。実施形態では、この応答は、トークンによって表されるデーターが宛先ファイルに首尾良く書き込まれたか否か、そしてどの位のデーターが書き込まれたかを示す。他の実施形態では、オフロード・ライト要求は、ファイル・ストレージ、またはオフロード・ライト要求を扱う役割を担う他のコンポーネントから直接クライアントに渡される。

[0061] 図５に戻り、本開示の実施形態にしたがって、サーバーにおいてオフロード・ライト応答が受信され（３５４）、クエリー３５６は、次に、データーの全てが宛先に書き込まれたか否か、またはライトが短縮されたか否か判定を行う。ライトが短縮された場合、要求データーの一部が宛先に書き込まれたことになり、プロセス３００はＹＥＳに進み、短縮ライト応答３５８をクライアントに渡す。次いで、フロー３００は３１６において終了する。クエリー３５６に戻り、要求データーの全てが宛先に書き込まれたとクエリー３５６において判定された場合、プロセス３００はＮＯから動作３６０に進み、基礎ファイル記憶システムからの応答がクライアントに渡される。次いで、フロー３００は３１６において終了する。

[0062] このように、実施形態では、要求がファイル・ストレージのような下位レイヤーに渡される場合であっても、サーバー自体がライトを短縮することもできる。例えば、サーバーは、実施形態によれば、書き込み要求を処理する時間が所定の閾値を超える場合、ライトを短縮することができる。実施形態では、サーバーは、要求を下位レイヤーに渡す前にライトを短縮する。例えば、短縮は、オフロード・ライト要求をファイル・ストレージに送る前に行うことができる。他の実施形態では、サーバーは、下位レイヤー、例えば、ファイル・ストレージによる処理の後に、ライトを短縮する。先に論じたように、フロー３００は、実施形態にしたがって実行することができる動作フローの一例に過ぎない。実施形態は、図３〜図５に関して以上で行った具体的な説明に限定されるのではなく、追加の動作を含むこともできる。例えば、図示した動作ステップを他のステップに組み合わせること、および／または並び替えることもできる。更に、例えば、もっと少ないステップまたはもっと多いステップを使用することもできる。

[0063] 図６に移ると、動作フロー４００は、オフロード・ファイル動作を要求するステップを示す。実施形態では、フロー４００は、クライアント２０２および２０４（図２）のようなクライアントにおけるリディレクターによって実行することができる。これらのリディレクターは、ファイル・システムにおけるファイルにアクセスするために、ファイル・サーバーと通信している。クライアントは、実施形態では、ＳＭＢプロトコルの一バージョンまたはＮＦＳの位置バージョンというような、ファイル・アクセス・プロトコルを使用して、ファイル・サーバーと通信する。

[0064] フロー４００は、動作４０２において開始し、ファイル・サーバーに接続する要求が送られる。動作４０２において送られる要求は、ファイル・サーバーを介してアクセス可能なファイル・システムに格納されているファイル情報にアクセスするために、ファイル・サーバーとのセッションを作るための要求である。この要求は、サーバー、例えば、サーバー２０６（図２）におけるファイル・サーバーに送ることができる。この要求は、ＳＭＢまたはＮＦＳの一バージョンのような、ファイル・アクセス・プロトコルにしたがってフォーマットされる。

[0065] 動作４０２の後、フロー４００は動作４０４に移り、セッションが作られたことを示す応答が受信される。実施形態の中には、動作４０２および４０４が、クライアントとサーバーとの間でセッションをネゴシエートするために交換される複数のメッセージの内一部であってもよい場合がある。メッセージの交換は、オフロード・ファイル動作にサービスするフィル・サーバーの能力を含む、能力の交換を含むことができる。

[0066] 動作フローは動作４０４から動作４０６に移り、ファイルを開く要求が送られる。フロー４００は動作４０６から動作４０８に移り、ファイルへのアクセスを付与する応答が受信される。動作４０８から、フローは動作４１０に移り、クライアントはオフロード・リード要求を送る。このオフロード・リード要求は、要求されたファイル・データーの一部を示す。また、このオフロード・リード要求は、本質的に、データーが、オフロード・リード要求に応答して送られるトークンによって表されることを要求する。動作４１２において、トークンを含むオフロード・リード応答が受信される。

[0067] 実施形態では、動作４１０においてオフロード・リード要求を送ったクライアントは、リード要求においてそれが要求できるデーターについて、何らかの制限を受けることもある。例えば、実施形態では、クライアントが一部のデーターをローカルにキャッシュした場合、そのリード要求を送る前に、キャッシュされているあらゆる「ダーティ」データーをフラッシュする(flush)。オフロード・リードを送る前に、キャッシュされているダーティ・データーをサーバーにフラッシュし損ねると、オフロード・リードが、古い(stale)データーを表すトークンを供給するという結果になる可能性がある。実施形態の中には、クライアント自体がオフロード・リードを短縮できる場合もある。言い換えると、ファイル・データーの全範囲を要求せず、これによってダーティなキャッシュ・データーを除外することもできる。

[0068] 動作４１２に続いて、クライアントは動作４１４においてオフロード・ライト要求を送ることができる。フロー４００は、動作４１４が動作４１２の直後にくることを示すが、これは例示の目的のために過ぎないことは言うまでもない。他の実施形態では、フロー４００を実行するクライアントが、データーを表すトークンを他の何らかの手段から受信する場合、動作４１４において送られたオフロード・ライト要求は、動作４１０において送られた要求のような、任意のオフロード・リード要求の前に実行することができる。

[0069] 実施形態では、動作４１４においてオフロード・ライト要求を送ったクライアントも、オフロード・ライト要求において送ることができるデーターに関して何らかの制限を受けることもある。オフロード・ライトが、トークン・データーを、ダーティ・データーをキャッシュしている宛先オフセットに書き込むことが許されると、キャッシュされているダーティ・データーがストレージに書き戻されるときに、このキャッシュされているダーティ・データーが、オフロード・ライトによって書き込まれたデーターを後に誤って上書きすることになる。オフロード・ライトを送るクライアントは、キャッシュされているダーティ・データーをクライアントが保持する位置のオフセットに対するライト要求はいずれも、送ることを回避すればよい。実施形態によれば、クライアントは、オフロード・ライト自体を短縮するのでもよく、またはキャッシュされているダーティ・データーがオフロード・ライトの宛先のオフセットと重複するときは、キャッシュされているダーティ・データーを破棄するのでもよく、またはクライアントがオフロード・ライトを実行しなくてもよい。

[0070] オフロード・ライト要求が動作４１４において送られた後、フロー４００は動作４１６に移り、オフロード・ライト要求に対する応答が受信される。この応答は、オフロード・ライト要求において送られたトークンが首尾良く宛先ファイルに書き込まれたか否かを示すことができる。データーが部分的に書き込まれたかもしれない実施形態では、動作４１６において受信される応答は、首尾良く書き込まれたデーターの部分を注記し、データーの全てが宛先ファイルに書き込まれたのではないことを示す。

[0071] 破線で示す動作４１８は、実施形態によってはフロー４００の実行中の任意の時点において実行される。図６に示す実施形態では、動作４１８は動作４１６の後に示されているが、実施形態は必ずしもこの順序に限定されるとは限らない。フロー４００を実行するクライアントが、トークンに関連する実際のデーターを要求する実施形態では、 動作４１８に進む(sent)。即ち、このクライアントは、オフロード・リード要求を送ることによってまたは何らかの他の手段によってそれが受信したトークンを所持することができる。しかしながら、クライアントは、例えば、実際のデーターを要求しているアプリケーションにデーターを供給するために、トークンに関連する実際のデーターを必要とする場合がある。これらの実施形態では、動作４１８は、トークンに関連するデーターの一部を引き出す要求を送ることができる。クライアントは、実際のデーターを供給することができるサーバーに、データーを引き出す要求を送る。応答して、クライアントは実際のデーターを受信し、このデーターを、実際のデーターを要求するアプリケーションに供給することができる。これは、実施形態において一部のクライアントによって実行することができる１つの追加動作に過ぎない。フロー４００は４２０において終了する。

[0072] 先に注記したように、フロー３００および４００は、実施形態にしたがって実行することができる動作フローの一例に過ぎない。実施形態は、図３〜図６に関して先に行った具体的な説明には限定されず、追加の動作を含むこともできる。更に、図示した動作ステップを他のステップと組み合わせること、および／または並び替えることもできる。更に、例えば、もっと少ないステップまたはもっと多いステップを使用することもできる。

[0073] 図７は、一般的なコンピューター・システム７００を示す。これは、本明細書において説明した実施形態を実現するために使用することができる。コンピューター・システム７００は、計算環境の一例に過ぎず、コンピューターおよびネットワーク・アーキテクチャーの使用範囲や機能について何ら限定を示唆しようとするのでもない。また、コンピューター・システム７００が、コンピューター・システム例７００において図示されているコンポーネントのいずれの１つまたは組み合わせに関しても何らかの依存性や要件を有するように解釈してはならない。実施形態では、システム７００は、図１に関して先に説明したクライアントおよび／またはサーバーとして使用することができる。

[0074] システム７００は、その最も基本的な構成では、通例少なくとも１つの処理ユニット７０２とメモリー７０４とを含む。計算デバイスの正確な構成およびタイプに依存して、メモリー７０４は揮発性（ＲＡＭのような）、不揮発性（ＲＯＭ、フラッシュ・メモリー等のような）、または何らかの組み合わせとすることができる。この最も基本的な構成は、図７において破線７０６によって示されている。システム・メモリー７０４は、ストレージ７０８のようなストレージを含むファイル記憶システムに格納することができるデーター７２０を表すトークン７２３のようなデーターを格納する。

[0075] コンピューター読み取り可能媒体という用語は、本明細書において使用する場合、コンピューター記憶媒体を含むことができる。コンピューター記憶媒体は、揮発性および不揮発性、リムーバブルおよび非リムーバブル媒体を含むことができ、コンピューター読み取り可能命令、データー構造、プログラム・モジュール、または他のデーターというような情報の格納のための任意の方法または技術で実現される。システム・メモリー７０４、リムーバブル・ストレージ、および非リムーバブル・ストレージ７０８は全て、コンピューター記憶媒体の例である（即ち、メモリー・ストレージ）。コンピューター記憶媒体は、ＲＡＭ、ＲＯＭ、電子的消去可能なリード・オンリー・メモリー（ＥＥＰＲＯＭ）、フラッシュ・メモリーまたは他のメモリー技術、ＣＤ−ＲＯＭ、ディジタル・バーサタイル・ディスク（ＤＶＤ）または他の光ストレージ、磁気カセット、磁気テープ、磁気ディスク・ストレージまたは他の時期記憶デバイス、あるいは情報を格納するために使用することができ計算デバイス７００によってアクセスすることができる任意の他の媒体を含むことができるが、これらに限定されるのではない。このようなコンピューター記憶媒体はいずれも、デバイス７００の一部であってもよい。また、計算デバイス７００は、キーボード、マウス、ペン、サウンド入力デバイス、タッチ入力デバイス等のような入力デバイス（１つまたは複数）７１４も含むことができる。ディスプレイ、スピーカー、プリンター等のような出力デバイス（１つまたは複数）７１６も含むことができる。以上のデバイスは例であり、他のものを使用してもよい。

[0076] コンピューター読み取り可能媒体という用語は、本明細書において使用する場合、通信媒体も含むことができる。通信媒体は、コンピューター読み取り可能命令、データー構造、プログラム・モジュールまたは他のデーターによって、搬送波のような変調データー信号または他の伝達メカニズム(transport mechanism)において具体化することができ、任意の情報配信媒体を含む。「変調データー信号」という用語は、当該信号において情報をエンコードするようなやり方で、１つ以上の特性が設定または変更されている信号を記述することができる。一例として、そして限定ではなく、通信媒体は、有線ネットワークまたは直接有線接続のような有線媒体と、音響、無線周波（ＲＦ）、赤外線、および他のワイヤレス媒体のようなワイヤレス媒体とを含むことができる。

[0077] 本明細書にわたって、「一実施形態」または「実施形態」に言及したが、特定の説明された特徴、構造、または特性が少なくとも１つの実施形態に含まれることを意味する。つまり、このような句の使用は、単に１つよりも多い実施形態に言及することができる。更に、説明した特徴、構造、または特性は、１つ以上の実施形態では、任意の適したやり方で組み合わせることもできる。

[0078] しかしながら、関連技術における当業者であれば、実施形態は、前述の具体的な詳細の内１つ以上がなくても、あるいは他の方法、リソース、材料等を用いても実施できることを認めることができよう。その一方で、周知の構造、リソース、または動作を詳細に示さず説明しなかったのは、単に実施形態の形態を曖昧にするのを避けるためである。

[0079] 以上、実施形態例および用途について例示および説明したが、実施形態は以上で説明した構成およびリソースそのものに限定されるのではないことは言うまでもない。当業者には明白な種々の変更、変化、および変形は、特許請求する実施形態の範囲から逸脱することなく、本明細書において開示した方法およびシステムの構成、動作、および詳細において行うことができる。

Claims (10)

1. トークン・ベース・ファイル動作を行うコンピューター実装方法であって、
   ファイル・システムにおける情報にアクセスするために、ファイル・サーバーにおいて、前記ファイル・サーバーに接続することを求める第１要求を受けるステップと、
   前記ファイル・サーバーから第１応答を送るステップであって、前記応答が、前記ファイル・システムにおける前記情報へのアクセスを可能にするために、クライアントとのセッションを作る、ステップと、
   前記ファイル・サーバーにおいて、前記ファイルからのファイル情報にアクセスするために前記ファイル・システムにおいてファイルを開くことを求める第２要求を受けるステップと、
   前記第２要求を受けたことに応答して、前記ファイル・サーバーが前記クライアントに第２応答を送り、前記ファイルへのアクセスを付与するステップと、
   前記ファイル・サーバーにおいて、前記ファイルの一部からの第１データーのオフロード・リードを求める第３要求を受けるステップであって、前記第３要求が、ファイル・アクセス・プロトコルにしたがってフォーマットされる、ステップと、
   前記第３要求を受けたことに応答して、前記ファイル・サーバーが、前記第１データーを表すトークンと共に第３応答を送るステップであって、前記第１データーが論理的に前記ファイルの前記一部から読み出され、前記第３応答が前記ファイル・アクセス・プロトコルにしたがってフォーマットされる、ステップと、
   を含む、方法。
2. 請求項１記載の方法において、前記第３要求が、前記ファイルから読み出される第１データーと、前記ファイルから読み出される第２データーとを示し、前記第３応答が、前記第１データーを表す前記トークンと、前記第２データーを表す第２トークンとを含む、方法。
3. 請求項１記載の方法において、前記第３要求が、第１ファイルの第１部分と第２ファイルの第２部分とを示し、前記第３応答が、前記第１ファイルの前記第１部分から論理的に読み出された第１データーを表す前記トークンと、前記第２ファイルの前記第２部分から論理的に読み出された第２データーを表す第２トークンとを含む、方法。
4. 請求項１記載の方法であって、更に、
   前記ファイル・サーバーにおいて、前記第１データーの要求された部分の第２ファイルへのオフロード・ライトを求める第４要求を受けるステップであって、前記第４要求が、前記トークンを含み、前記ファイル・アクセス・プロトコルにしたがってフォーマットされる、ステップと、
   前記第４要求を受けたことに応答して、前記ファイル・サーバーが、
   前記第１データーの前記要求された部分を前記第２ファイルに書き込むステップと、
   前記第１データーの前記要求された部分が前記第２ファイルに書き込まれたことを示す第４応答を送るステップであって、前記第４応答が前記ファイル・アクセス・プロトコルにしたがってフォーマットされる、ステップと、
   を含む、方法。
5. 請求項１記載の方法であって、更に、
   前記ファイル・サーバーにおいて、前記第１データーの要求された部分の第２ファイルへのオフロード・ライトを求める第４要求を受けるステップであって、前記第４要求が前記トークンを含み、前記ファイル・アクセス・プロトコルにしたがってフォーマットされる、ステップと、
   前記第４要求を受けたことに応答して、前記ファイル・サーバーが、
   前記第１データーの前記要求された部分の内第１部分を前記第２ファイルに書き込むステップであって、前記要求された部分の前記第１部分が、前記第１データーの前記要求された部分の全て未満である、ステップと、
   前記第１データーの前記要求された部分の内前記第１部分が前記第２ファイルに書き込まれたことを示す第４応答を送るステップであって、前記第４応答が、前記ファイル・アクセス・プロトコルにしたがってフォーマットされる、ステップと、
   を含む、方法。
6. コンピューター実行可能命令を含むコンピューター読み取り可能記憶媒体であって、前記コンピューター実行可能命令をプロセッサーによって実行すると、トークン・ベース・ファイル動作を要求する方法を実行し、前記方法が、
   ファイル・システムにおける情報にアクセスするために、ファイル・サーバーに接続することを求める第１要求をクライアントによって送るステップと、
   第１応答を受信するステップであって、前記応答が、前記ファイル情報へのアクセスを可能にするために前記クライアントとのセッションを作る、ステップと、
   前記ファイル・システムにおいてファイルを開くことを求める第２要求を送るステップと、
   前記ファイルへのアクセスを付与する第２応答を受信するステップと、
   トークンによって表されるデーターの第１部分のファイルへのオフロード・ライトを求める第３要求を送るステップであって、前記第３要求が、サーバー・メッセージ・ブロック（ＳＭＢ）プロトコルの一バージョンにしたがってフォーマットされ、前記データーを表す前記トークンを含む、ステップと、
   応答を受信するステップと、
   を含む、コンピューター読み取り可能記憶媒体。
7. 請求項６記載のコンピューター読み取り可能記憶媒体において、前記応答が、前記データーの第２部分が前記ファイルに首尾良く書き込まれたことを示し、前記第２部分が、前記第１部分におけるデーターの全て未満を表す、コンピューター読み取り可能記憶媒体。
8. 請求項６記載のコンピューター読み取り可能記憶媒体であって、更に、
   第２ファイルの一部からの第２データーのオフロード・リードを求める第４要求を送るステップであって、前記第４要求が、前記ＳＭＢプロトコルの前記バージョンにしたがってフォーマットされる、ステップと、
   前記第２データーを表すトークンと共に第４応答を受信するステップであって、前記第４応答が、前記ＳＭＢプロトコルの前記バージョンにしたがってフォーマットされる、ステップと、
   を含む、コンピューター読み取り可能記憶媒体。
9. トークン・ベース・ファイル動作を可能にするシステムであって、
   少なくとも１つのサーバーを含み、このサーバーが、
   コンピューター実行可能命令を実行するように構成された少なくとも１つのプロセッサーと、
   前記コンピューター実行可能命令を格納する少なくとも１つのコンピューター読み取り可能媒体と、
   を含み、前記少なくとも１つのプロセッサーによって前記コンピューター実行可能命令を実行すると、ファイル・サーバーを設け、このファイル・サーバーが、
   ファイルの一部からデーターのオフロード・リードを求める要求を受け、前記要求が、サーバー・メッセージ・ブロック（ＳＭＢ）プロトコルの一バージョンにしたがってフォーマットされ、
   前記要求を受けたことに応答して、前記ファイル・サーバーが、前記データーを表すトークンと共に応答を送り、前記応答が、前記ＳＭＢプロトコルの前記バージョンにしたがってフォーマットされる、
   ように構成された、システム。
10. 請求項９記載のシステムにおいて、前記システムが、更に、
    少なくとも１つのクライアントを含み、このクライアントが、
    コンピューター実行可能命令を実行するように構成された少なくとも１つのプロセッサーと、
    前記コンピューター実行可能命令を格納する少なくとも１つのコンピューター読み取り可能記憶媒体と、
    を含み、前記少なくとも１つのプロセッサーによって前記コンピューター実行可能命令を実行すると、
    前記ファイルの前記一部からのデーターの前記オフロード・リードを求める前記要求を送り、
    前記データーを表す前記トークンと共に前記応答を受信する、システム。

Images