AAA/BBB/CCC/文件名)的哈希值和i_节点编号相互关联地记录在根据本实施例的平路径表中。当游戏程序输出包括全路径信息的文件读出请求时，OS中的文件读出API(应用编程接口)顺序地获得全路径的哈希值，使用哈希值搜寻平路径表中的i_节点编号，并且标识构成文件的块。
[0096]图12A示出平路径表的示例。在平路径表220中，将每一段全路径信息的哈希值和相应于全路径信息的i_节点编号互相关联地加以记录。此处，例如，将哈希值作为4个字节的值加以形成。于是，可以形成全路径信息的哈希值，从而能够以与全路径信息的数据量相比极小的数据量加以表示。在平路径表220中，按递降的次序排列全路径信息的哈希值。在这一情况下，为了便于描述，将哈希值表示为16进制数字。
[0097]另一方面，当使用哈希值时，多段全路径信息的哈希值可能相同。通常将这称为“哈希值冲突”。在平路径表220中，用由少量数据表示的哈希值取代全路径信息，因此可能出现哈希值之间的冲突。在这一情况下，会同时存在与不同i_节点编号相关联的相同的哈希值。因此，为了互相区别这些哈希值，平路径表220将冲突文件222定义为伴随平路径表220的文件。
[0098]图12B示出冲突文件的示例。在冲突文件222中，对于其哈希值互相冲突的全路径信息，将文件名和用于标识文件的记录位置的信息(在这一情况下为i_节点编号)互相关联地加以记录。
[0099]将描述图12A的表中的右项中的“1-节点编号/位移”。例如，这一项由4个字节表示，在高阶比特中设置至少指示冲突存在或者不存在的信息。假设，在一个示例中，将这一信息准备为冲突标志，并且假设当存在冲突时设置冲突标志1，当不存在冲突时设置冲突标志O。
[0100]因此，在平路径表220中，对于不存在其重复哈希值的哈希值(无冲突的哈希值)，将高阶比特的冲突标志设置为0，并且在低阶比特中描述1-节点编号。当游戏程序输出指定全路径信息的文件读出请求时，OS中的文件读出API获得全路径信息的哈希值，并且使用哈希值搜寻在存储器中扩展的平路径表中的i_节点编号。此时，当相应的哈希值是非冲突的哈希值时(即，当将冲突标志设置为O时)，文件读出API标识所述表中的右项中所描述的i_节点编号，并读出该文件。
[0101]另一方面，在平路径表220中，对于存在其重复哈希值的哈希值(冲突的哈希值)，将高阶比特的冲突标志设置为1，并且在低阶比特中描述位移信息。此处，位移信息指示记录位置相对冲突文件的位移，并且是标识描述了在冲突文件中包括的数据的第一位置的信息。当游戏程序输出指定全路径信息的文件读出请求时，OS中的文件读出API获得全路径信息的哈希值，并且使用哈希值搜寻在存储器中扩展的平路径表中的i_节点编号。此时，当相应的哈希值是冲突的哈希值时(即，当将冲突标志设置为I时)，文件读出API使用位移信息来访问冲突文件，并且搜寻在冲突文件中记录的数据。
[0102]例如，当读出请求所指定的全路径信息的哈希值为“012B341C”，并且在表的右项中将冲突标志设置为I时，读出API引用冲突文件，并且搜寻被请求以读出的文件的文件名。如图12B中所示，在冲突文件中，将文件名和1-节点编号互相关联地加以记录。读出API搜寻冲突文件的内部，并且找出被请求以读出的文件的文件名。将i_节点编号与冲突文件中的文件名相关联。于是，读出API能够根据文件名标识i_节点编号，并且读出该文件。
[0103]因此，通过取代图像文件210或者212的元数据区域204中的全路径信息，而准备平路径表和冲突文件，可以减小在程序执行期间读出到存储器中的元数据的量。
[0104]以下将描述超级根目录。
[0105]图13A示出普通根目录和低层的子目录。针对游戏程序的执行所需的每一种文件，形成子目录。所述内核可以通过在预先确定的执行安装点处安装根目录来执行游戏程序。
[0106]图13B示出本实施例中所使用的超级根目录和低层的子目录。在高于根目录的层的层上设置超级根目录，根目录是所述超级目录的子目录。顺便提及，还是在图13B中所示的目录结构中，所述内核可以通过安装超级根目录来执行根目录的启动文件。由于在较高的层上提供了超级目录，所以能够在低于根目录的层的层上无任何变化的情况下，容易地将子目录添加于低于从根目录独立分支的超级目录的层的层。例如，这使平路径表的文件能够被设置在低于超级目录的层的层。因此，能够提供具有良好可扩展性的文件系统。
[0107]图14示出用于实现访问在游戏数据中包括的文件的文件访问功能的配置。信息处理设备10包括接收部分100、哈希值推导部分102、i_节点编号获得部分104、以及文件访问部分106。在硬件部件方面，由任意计算机的CPU、存储器、加载于存储器中的程序、存储装置等实现这些构成元件。然而，在这一情况下，描述了通过这些部件的协作所实现的功能块。因此，本领域技术人员将会意识到:可以仅通过硬件、仅通过软件、或者通过硬件与软件的组合按各种形式实现这些功能块。此处，可以通过以上所描述的读出API实现接收部分100、哈希值推导部分102、以及i_节点编号获得部分104的功能。
[0108]在游戏的执行期间，接收部分100从游戏接收包括文件的全路径信息的读出请求。哈希值推导部分102根据预先确定的哈希函数推导所接收的全路径信息的哈希值。1-节点编号获得部分104引用配置为对应文件的平路径表220，并且使用哈希值获得用于标识文件的记录位置的信息，或者这一情况下的i_节点编号。于是，文件访问部分106可以使用i_节点编号来访问游戏所指定的文件，并且读出该文件。
[0109]应该加以注意的是，以上表示在哈希值推导部分102所推导的哈希值为非冲突哈希值的情况下的文件访问操作。当将所推导的哈希值的冲突标志设置为O时，1-节点编号获得部分104判断哈希值不冲突，并且能够从平路径表220获得1-节点编号。
[0110]在哈希值推导部分102所推导的哈希值为冲突的哈希值的情况下，i_节点编号获得部分104判断哈希值冲突，因为将所推导的哈希值的冲突标志设置为I。因此，1-节点编号获得部分104使用与哈希值相关联的位移信息来访问冲突文件222，并且搜寻冲突文件222中的全路径信息中所指定的文件名。当找到冲突文件222中的文件名时，1-节点编号获得部分104获得与该文件名相关联的1-节点编号。于是，当哈希值推导部分102所推导的哈希值冲突时，i_节点编号获得部分104引用冲突文件222，并且从文件名获得1-节点编号。因此，文件访问部分106可以使用i_节点编号访问游戏所指定的文件，并且读出该文件。
[0111]如以上所描述的，文件访问部分106使用i_节点编号来访问该文件。在根据本实施例的信息处理设备10中，作为缓冲器操作的存储器(例如，DDR3)、辅助存储设备2、以及ROM介质44以存储文件的存储部分的形式出现。将ROM介质44加载于介质驱动器32中，以便将数据从ROM介质44读出。此处，将存储器、辅助存储设备2、以及介质驱动器32的相应数据读出速度互相进行比较可以看出:数据读出速度依存储器(memory)、辅助存储设备2、以及介质驱动器32的这一次序而下降。
[0112]在这一情况下，在本实施例中，存储器将被称为高速设备，辅助存储设备2将被称为中速设备，并且介质驱动器32将被称为低速设备。以下将描述用于提高文件访问处理的速度的机制，其中，所述机制主要考虑的是数据读出速度的差别。
[0113]顺便提及，在描述提高速度的机制之前，由于在ROM介质44上记录的游戏软件70的执行期间、信息处理设备10具有将在ROM介质44上记录的游戏软件70拷贝至辅助存储设备2的功能，所以将首先描述这一拷贝功能。
[0114]图15示出用于实现文件管理功能的配置。信息处理设备10包括用于进行文件访问的文件访问部分106和用于进行文件管理的文件管理部分108。文件管理部分108也具有将游戏软件70从ROM介质44拷贝至辅助存储设备2的功能。作为存储文件的存储部分120，信息处理设备10具有作为高速存储设备的存储器110、作为中速存储设备的辅助存储设备2、以及作为低速存储设备的介质驱动器32。将存储器110连接于辅助存储设备2或者介质驱动器32。存储器110具有临时存储从辅助存储设备2或者介质驱动器32读出的数据的功能。顺便提及，为了更高速的文件访问，预先在存储器110中扩展图10中所示的在元数据区域204中包括的元数据。
[0115]如参照图14所描述的，文件访问部分106使用i_节点编号，访问游戏在全路径信息中所指定的文件，并且读出该文件的数据。具体地讲，文件访问部分106将文件数据从ROM介质44的记录区域(所述记录区域由i_节点编号标识)读出到存储器110中，从存储器110获得文件数据，并且将文件数据提供至该游戏程序。
[0116]图16是辅助解释拷贝处理的示例的图。这一拷贝处理假设游戏程序正被执行。当游戏程序请求该数据的读出时，文件访问部分106从介质驱动器32读出在ROM介质44上记录的数据，而存储器110临时存储所读出的数据(ST1)。文件访问部分106将在存储器110中存储的数据提供至该游戏程序(ST2)。于是，游戏程序可以使用被请求读出的数据来推进该游戏。
[0117]此时，文件管理部分108读出在存储器110中存储的数据，并且将数据记录在辅助存储设备2中(ST3)。于是，通过不仅根据来自游戏程序的请求向游戏程序提供读出到存储器110中的数据，而且还将数据记录在辅助存储设备2中，可以将数据从低速设备拷贝至中速设备。当游戏程序下一次需要数据时，将拷贝至辅助存储设备2的数据从辅助存储设备2读出至游戏。
[0118]文件管理部分108管理从ROM介质44拷贝至辅助存储设备2的文件。例如，文件管理部分108可以管理指示是否拷贝了文件的信息，作为针对一个文件的位图(bitmap)。顺便提及，在本实施例中，文件由一个或多个块构成。因此，期望文件管理部分108以块为单位管理指示是否拷贝了块的信息。当文件管理部分108已经将数据块从ROM介质44拷贝至辅助存储设备2时，文件管理部分108设置指示将相应数据块拷贝在块位图上的信息(标志)，从而更新块位图(ST4)。于是，文件管理部分108可以识别将哪个块从ROM介质44拷贝至辅助存储设备2。
[0119]图17示意性地示出存储部分120的各存储单元的存储区域的状态。顶行示出作为高速设备的存储器110的存储区域的状态。中间行描述了作为中速设备的辅助存储设备2的存储区域的状态。底行描述了作为低速设备的ROM介质44的存储区域的状态。在示意性地示出各存储区域的水平方向为长的矩形区域中，由垂直线所划分的区域表示多个块，画阴影线的块表示已经将数据存储在这些存储区域中。
[0120]在这一情况下，顶行所示的存储器110将元数据存储在元数据区域204中，并且还将一部分游戏数据临时存储在其余的存储区域中。由于存储器110的存储区域的大小很小，所以可以通过最小化在元数据区域204中包括的元数据的大小来扩展临时存储游戏数据的区域。顺便提及，在这一情况下，将存储器110的存储区域示出为好像充分使用。然而，实际上，存储器110的存储区域仅代表存储器110中的预先确定大小的存储区域，因此，并