U.S. patent application number 11/972556 was filed with the patent office on 2011-12-01 for managing computer file system using file system trees.
This patent application is currently assigned to SWsoft Holdings, Ltd.. Invention is credited to ALEXANDER G. TORMASOV.
Application Number | 20110295901 11/972556 |
Document ID | / |
Family ID | 40851583 |
Filed Date | 2011-12-01 |
United States Patent
Application |
20110295901 |
Kind Code |
A9 |
TORMASOV; ALEXANDER G. |
December 1, 2011 |
MANAGING COMPUTER FILE SYSTEM USING FILE SYSTEM TREES
Abstract
A system, method and computer program product for managing
computer file system using file system trees. A plurality of
Virtual Execution Environments (VEEs) running on a computer system
is provided. The computer system has a common file system tree,
which can be concurrently accessed by the VEEs. The shareable files
are stored in the common file system tree located in a local
storage of the computer system. The common file system tree
includes a first set of files that can be accessed by VEEs directly
using first redirection. The common file system tree also includes
a second set of files that can be accessed by VEEs using first and
second redirection. The files system accesses the files from the
local storage using first redirection and from the network storage
using first and second redirection. The local storage can also
receive files from the network storage and store them in the common
file system tree.
Inventors: |
TORMASOV; ALEXANDER G.;
(Moscow, RU) |
Assignee: |
SWsoft Holdings, Ltd.
Herndon
VA
|
Prior
Publication: |
|
Document Identifier |
Publication Date |
|
US 20090182778 A1 |
July 16, 2009 |
|
|
Family ID: |
40851583 |
Appl. No.: |
11/972556 |
Filed: |
January 10, 2008 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
11378268 |
Mar 20, 2006 |
7584228 |
|
|
11972556 |
|
|
|
|
Current U.S.
Class: |
707/793 |
Current CPC
Class: |
G06F 16/176
20190101 |
Class at
Publication: |
707/793 |
International
Class: |
G06F 7/00 20060101
G06F007/00; G06F 17/30 20060101 G06F017/30 |
Claims
1. A method for managing a computer file system, the method
comprising: on a remote computing system, creating a Virtual
Execution Environment (VEE) file template for a plurality of VEEs,
each VEE having a VEE file system located on a local computing
system; establishing, on the local computing system, a common
template file system tree that is concurrently accessible by the
VEEs; on a local computing system, instantiating a VEE that uses
the VEE file template; transmitting the VEE file template from the
remote computing system to the common template file system tree;
and providing access from the VEE to the file template in the
common template file system tree.
2. A method for managing a computer file system, the method
comprising: establishing a common template file system tree that is
concurrently accessible by a plurality of Virtual Execution
Environments (VEEs); instantiating a VEE on a computer system;
launching the VEEs together with the VEE file system tree; where
after any of the VEEs requests access to a file from the VEE file
system tree, if the requested file is stored on network storage,
copying the file into the common template file system tree from the
network storage, wherein the common template file system tree is
located on local storage; and redirecting file access requests from
the VEE file system tree to the common template file system on the
local storage.
3. The method of claim 2, wherein the requested file is stored on
the network storage along with files forming a file template set,
and further comprising loading the file template set after an
attempt to load the file template.
4. The method of claim 2, wherein, if the requested file is stored
on the network storage, the method further comprises recognizing a
portion of file requested by the VEE, copying the portion to the
local storage and providing access to the portion as if it were the
entire file.
5. The system of claim 2, wherein the common template file system
tree comprises stub files that reference files on the network
storage.
6. The system of claim 5, wherein the stub files include
metadata.
7. The system of claim 2, wherein the VEE file systems are stored
on the local storage.
8. The system of claim 2, wherein the common template file system
tree is associated with a downloading utility that is activated by
the request and downloads the requested files and/or templates to a
local machine.
9. The system of claim 2, wherein the common template file system
tree provides the requested file, by the VEE, to the file
system.
10. A method for managing a computer file system, the method
comprising: launching a plurality of Virtual Execution Environments
(VEEs) on a computer system; creating a VEE file system for each
VEE; establishing a common template file system tree that is
concurrently accessed by the VEEs; requesting, by a VEE, a file
from the common template file system tree and copying the requested
file from the common template file system tree into the VEE file
system, if the requested file is available in the common template
file system tree, and copying the file into the common template
file system tree from the network storage and subsequently
providing the requested file from the common template file system
tree into the VEE file system, if the requested file is not
available in the common template file system tree; and providing
the file from the VEE file system to the VEE, wherein the VEE file
systems and the common template file system tree are stored on a
local storage of the computer system.
11. The method of claim 10, wherein the VEE file system includes
stub files referencing files in the common template file system
tree.
12. The method of claim 10, wherein the common template file system
tree includes stub files referencing files on the network
storage.
13. The method of claim 10, wherein copying the file into the
common template file system tree from the network storage is
performed via a downloading utility.
14. The method of claim 13, wherein the downloading utility
downloads and caches files according to predefined rules.
15. The method of claim 14, wherein the common template file system
tree communicates with the downloading utility by I/O
redirections.
16. The method of claim 10, wherein the file is provided to the VEE
by I/O processing.
17. A computer useable recording medium having computer executable
program logic stored thereon for executing on a processor for
performing the method of claim 10.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] This patent application is related to co-pending application
Ser. No. 11/779,258 filed on Jul. 17, 2007, entitled "Effective
File Sharing Among Virtual Environments," which is a
continuation-in-part of co-pending application Ser. No. 10/691,066,
filed Oct. 21, 2003, entitled "System And Method For Providing
Effective File-Sharing In A Computer System To Allow Concurrent
Multi-User Access," which is a continuation of co-pending
application Ser. No. 10/401,636, filed Mar. 27, 2003 entitled
"System and Method for Providing Effective File Sharing in a
Computer System to Allow Concurrent Multi-User Access," which
claims priority to provisional patent application Ser. No.
60/367,951, filed Mar. 27, 2002 and entitled "Method of Using Links
to Let Different Users Share a File Tree," which are all
incorporated by reference herein.
BACKGROUND OF THE INVENTION
[0002] 1. Field of the Invention
[0003] The present invention relates to computer systems and, more
particularly, to a system, method and computer program product for
managing a computer files system and for providing file sharing
among Virtual Execution Environments (VEEs) using file tree
systems.
[0004] 2. Description of Related Art
[0005] Typically, the operating system of a computer includes a
file system to provide users with an interface for working with
data on the computer system's disk and to provide the shared use of
files to several users and processes. Generally, the term "file
system" encompasses the totality of all files on the disk and the
sets of data structures used to manage files, such as, for example,
file directories, file descriptors, free and used disk space
allocation tables, and the like.
[0006] Accordingly, end-users generally regard the computer file
system as being composed of files and a number of directories. Each
file usually stores data and is associated with a symbolic name.
Each directory can contain subdirectories, files or both. The files
and directories are typically stored on a disk or similar storage
device.
[0007] Operating systems such as UNIX, Linux and Microsoft Windows
manage computer file systems by defining a file object hierarchy. A
file object hierarchy begins with a root directory and goes down
the file tree. The file address is then described as an access
path, e.g., a succession of directories and subdirectories leading
to the file. This process of assigning a file address is called
access path analysis or path traverse. For instance, the path
"I/r/a/b/file" contains the root directory (I), subdirectories "r",
"a" and "b" and then the file.
[0008] Typically, the processes within an operating system interact
with the file system with a regular set of functions. For example,
these functions usually include open, close, write and other system
calls or similar mechanisms. For instance, a file can be opened by
the open functions and this function acquires the file name as a
target.
[0009] The file system can also include intermediate data
structures containing data associated with the file system to
facilitate file access. This data is called metadata and may
include, for example, data corresponding to the memory location of
the files, e.g., where the file is located in the hard drive or
other storage medium. For example, in the context of a UNIX
operating system, these intermediate data structures are called
"inodes," i.e., index-node. An inode is a data structure that
contains information about files in UNIX file systems.
[0010] Each file has an inode and is identified by an inode number
(e.g., i-number) in the file system where it resides. The inodes
provide important information about files such as user and group
ownership, access mode (read, write, execute permissions) and type.
The inodes are created when a file system is created. There are a
set number of inodes, which corresponds to the maximum number of
files the system can hold.
[0011] Usually, computer file systems store this intermediate data
concerning the location of stored files as separate structures in
the same place as the file content is stored. The functions
responsible for file searching, implemented in the operating system
kernel, for example, first locate the intermediate data and then
locate the file data that is sought. Directories can also have
intermediate data structures containing metadata. File systems can
also generate intermediate file data "on the fly", for example, at
the moment when the file system is requesting the file. For
instance, the NFS Network file system used by Sun Microsystems,
provides for on the fly intermediate data creation.
[0012] In addition, intermediate data structures can include
reference files or links that are associated with or point to other
files. When a link is accessed, the link itself is not opened.
Instead, only the file the link refers to is opened. Thus, the
intermediate data structure in a link can contain data referring to
other files that are not requested. For instance, the intermediate
data structure can contain the path to another file that will be
found and opened instead of this reference link.
[0013] There are several types of links or references. For example,
references that include a symbolic name of another file are called
"symbolic links." References that refer to another file's
intermediate structure are called "hard links." The type of link
used is generally determined by the operating modes supported by
the operating system. File systems can provide several functions.
As discussed above, the most basic task of a file system is to
provide access to files. File systems can also enhance system
performance with additional functions such as, for example,
caching, access markers and fault-tolerance.
[0014] The multi-user operating mode of a computer system can
generally allow the operating system processes of different users
to operate simultaneously. Each process within the operating system
is usually associated with information that identifies the user.
For instance, in a UNIX system, this information is typically an
identifier of the user and group on whose behalf this process is
being executed. When accessing a file, the operating system defines
the user requesting the file operation and determines whether the
operation is permitted for that user.
[0015] Generally, this determination can be made upon opening the
file, e.g., using a file access mechanism of the OS, such as
requesting a function of the type "open." Thus, on the basis of
this access information, the operating system can organize
different views of the same file system tree based upon selected
parameters, such as, for example, time, operation type or user
information.
[0016] To unite different types of computer file systems, these
file systems can be mounted. For any directory inside the file
system, it is possible to mount another file system into that
existing directory. Thus, one tree of the computer file system
appears inside another file tree. The operating system uses a
specific system call of the operating system kernel to mount a file
system. This system call includes at least two arguments: the
mounting point, e.g., the directory inside of the current file
system, and the file system itself, e.g., the storage device or
memory location where the data resides. Depending on the file
system, additional information containing parameters of the
specific file system types can be included.
[0017] During analysis of the access path to the selected data
file, the operating system defines a moment when the path "passes"
through this mounting point and "below" this point, an analysis is
performed using operations specific for the given file system. The
set of these operations is defined according to the parameters
established during the file mounting process.
[0018] The UnionFS file system, developed in the FreeBSD UNIX
operating system, implements a similar technique. One feature of
UnionFS is that each user can have a different view of the tree of
the same file. In order to provide this feature, two trees of the
file system are built when mounting UnionFS. The first tree is a
read-only tree. The second tree is created during the user's
session and is used for auxiliary purposes. This second tree is
defined as an additional parameter when mounting.
[0019] When calling a file within the shareable tree, a search is
performed in two ways. First, the search can be based on a path
name that is computed based on the location of the file. For
example, the mounting point of UnionFS can be located at "a/b/u,"
and the file to be addressed can be at "/a/b/u/c/d/e." The second
tree, mounted to the same point, is located starting from the
address "/x/y/." Then an additional address is computed as
"/a/b/u/c/d/e" minus "/a/b/u" plus "/x/y/." As a result, the
additional address is computed as "/x/y/c/d/e."
[0020] Thus, the specific intermediate data structure (e.g., inode)
is searched using the computed path name. If the specific
intermediate data structure (inode) is found, then it is assumed
that the file is found and the requested operation will be
performed on this file. If the file is not found, then a second
search by the direct address is provided. If the file is not found
there either, the system returns the corresponding error code.
Otherwise, the system acts according to the requested operation. If
the file opens in response to an operation to modify its content or
associated data, then the file is first copied to the computed
address as described above, and the operation is performed on the
new copy. Otherwise, the operation is performed on the file located
in the shareable tree by the requested address.
[0021] One way to change the search address of the file object,
and, accordingly, the position of the root file system for a group
of processes, is to use a primitive that is analogous to the OS
UNIX kernel primitive "chroot." The operation of this primitive is
based on the principle of shifting the real root of the file system
or "root" directory to some location for a selected group of
processes, for instance, for all processes of one user. Then all
file operations inside this process kernel are performed only
within the sub-tree of the selected file system.
[0022] Another example of this type of system is one based upon
"snaps" of the file system, or tree snapshots, in which
modifications to the entire file system are chronologically
arranged. All modifications made in the file system or any of its
parts during a period of time are saved in a separate tree of the
file system. Such separate chronologically arranged trees represent
the complete history of file system modifications for a discrete
period of time. Thus, to determine the file state at a fixed moment
of time, the operator searches for the file in the most recently
accessed file tree. If the file is not located, then the previous
tree is searched.
[0023] Similarly, the Mirage File System (MFS) from IBM, describes
a system consisting of a number of trees and a specific file search
mechanism that depends on the file type, extension and sequence of
requests, among other parameters. One of the principles of this
computer file system is the substitution of the file search path
whereby the search path is expanded to other file system locations
associated with the file object being searched. For example, this
system offers an implementation of a system of snapshots.
[0024] U.S. Pat. No. 6,289,356 also describes an example of
implementation of specific intermediate data structures, in which
the file system is organized with a strictly regulated mode of
modifications records. The disclosed system provides the transition
of file system states so that at any moment of time the system is
in the correct state. Additionally, the system creates snapshots of
the file system through doubling an intermediate data structure
(e.g., inode) without doubling the files themselves. The system
also marks the files chosen to store data file blocks as belonging
to some snapshot of the file system. This provides interference
with file system functioning at the level of data distribution
algorithms.
[0025] The industry trend of virtualization and isolation of
computer system resources makes the task of file sharing more
complex. A Virtual Execution Environment (VEE), such as, for
example, Virtual Machine (VM) or Virtual Environment (VE) (for
example, a Virtual Private Server (VPS)), is a type of an isolated
VEEs that run on the same physical machine simultaneously. Each VEE
instance accesses its own files, as well as (in some cases) files
used by other VEEs.
[0026] Virtualization allows running a number of VEEs (such as VMs
or VEs/Virtual Private Servers) on the same physical machine or
processor. Thus, sharing file data among numerous VEEs executing on
the same machine becomes even more crucial. A robust file sharing
system is especially important in multi-user systems, such as, for
example, virtual server systems. A VE is a server, for example, a
Web server, that shares computer resources with other virtual
servers.
[0027] Instead of requiring a separate computer for each server,
dozens of virtual Web servers can co-reside on the same computer
system. In most cases, performance is not affected and each web
site behaves as if it is being served by a dedicated server. It is
also desirable to provide VEs with an access to shareable files
residing on network storage.
[0028] In addition to maintaining efficient allocation of
resources, providing multi-user access in Virtual Execution
Environment involves other considerations as well, including
security, avoiding file corruption and maximizing system
efficiency. Accordingly, it is desirable to have a method for
providing file sharing among Virtual Execution Environments (VEEs)
using file tree system that provides multi-user access to files
residing on the local storage as well as on the remote network
storage.
SUMMARY OF THE INVENTION
[0029] The present invention relates to a system, method and
computer program product for managing a computer files system and
for providing file sharing among Virtual Execution Environments
(VEEs) using file tree systems that substantially obviates one or
more of the disadvantages of the related art.
[0030] More particularly, in an exemplary embodiment, a file
management system includes a plurality of VEEs running under the
operating system of a computer system and a shareable file system
of the computer system. The shareable files are stored in the
common file system tree located in a local storage of the computer
system. A VEE file system accesses the files from the common system
file tree on local storage and from the network storage. According
to an exemplary embodiment, the local storage can also receive
files from the network storage and store them in the common file
system tree. This approach increases an overall fault-tolerance of
a computer system.
[0031] Additional features and advantages of the invention will be
set forth in the description that follows, and in part will be
apparent from the description, or may be learned by practice of the
invention. The advantages of the invention will be realized and
attained by the structure particularly pointed out in the written
description and claims hereof as well as the appended drawings.
[0032] It is to be understood that both the foregoing general
description and the following detailed description are exemplary
and explanatory and are intended to provide further explanation of
the invention as claimed.
BRIEF DESCRIPTION OF THE DRAWINGS
[0033] The accompanying drawings, which are included to provide a
further understanding of the invention and are incorporated in and
constitute a part of this specification, illustrate embodiments of
the invention and together with the description serve to explain
the principles of the invention. In the drawings:
[0034] FIG. 1 illustrates file visibility to different users in an
exemplary embodiment of the computer system;
[0035] FIG. 2 illustrates requested access to a non-link file in
accordance with an exemplary embodiment;
[0036] FIG. 3 illustrates the initial state of the user file area
in accordance with an exemplary embodiment;
[0037] FIG. 4 illustrates an exemplary embodiment of the user file
area;
[0038] FIG. 5 illustrates an exemplary embodiment of the proposed
method;
[0039] FIG. 6 illustrates an exemplary embodiment for file sharing
among users of multiple VEs;
[0040] FIG. 7 illustrates an exemplary embodiment of file
management in the computer system;
[0041] FIG. 8 illustrates a method for file management in
accordance with an exemplary embodiment;
[0042] FIGS. 9A-9C illustrate implementation of files system trees
in accordance with an exemplary embodiment;
[0043] FIG. 10 illustrates an exemplary computer system on which
the invention can be implemented.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
[0044] Reference will now be made in detail to the embodiments of
the present invention, examples of which are illustrated in the
accompanying drawings.
[0045] In the discussion herein, the following definitions are
used:
[0046] Virtual Execution Environment (VEE)--a type of environment
that supports program code execution, where at least a part of the
real hardware and software required for running program code are
presented as their virtual analogs. From the point of view or the
user, that the code in VEE runs as if it were running on the real
computing system.
[0047] Virtual Environment (VE)--is one type of a Virtual Execution
Environment running on the same hardware system with a shared OS
kernel and most of the system resources, where isolation of Virtual
Environments is implemented on the namespace level. Software
necessary for process execution is virtualized and provided to the
process. A VEE, such as a VE in a form of a Virtual Private Server
(VPS), is implemented in, for example, Virtuozzo.TM. OS
virtualization solution, available from SWsoft, Inc., as a closed
set, or collection, of processes, system resources, users, groups
of users, objects and data structures. Each VPS has its own ID, or
some other identifier, that distinguishes it from other VPSs.
[0048] Each VPS has its own ID, or some other identifier, that
distinguishes it from other VPSs. The VPS offers to its users a
service that is functionally substantially equivalent to a
standalone server with remote access. From the perspective of an
administrator of the VPS, the VPS should preferably act the same as
a dedicated computer at a data center. For example, it is desirable
for the administrator of the VPS to have the same remote access to
the server through the Internet, the same ability to reload the
server, load system and application software, authorize VPS users,
establish disk space quotas of the users and user groups, support
storage area networks (SANs), set up and configure network
connections and webservers, etc. In other words, the full range of
system administrator functions is desirable, as if the VPS were a
dedicated remote server, with the existence of the VPS being
transparent from the perspective of both the VPS user and the VPS
administrator.
[0049] Virtual Machine (VM)--a type of an isolated VEE running on
the same physical machine simultaneously. Each Virtual Machine
instance executes its own OS kernel. Support of Virtual Machines is
implemented using a Virtual Machine Monitor and/or a Hypervisor. An
example of a VM is a VMware Virtual Machine or a Parallels Software
International Virtual Machine.
[0050] Hypervisor--control software having the highest privilege
level for administrating hardware computer resources and Virtual
Machines. One embodiment of the Hypervisor is used in the Xen open
source project and virtualization for Windows Server "Longhorn"
(Veridian).
[0051] The present invention relates to a system, method and
computer program product for managing a computer files system and
for providing file sharing among Virtual Execution Environments
(VEEs) using file tree systems that substantially obviates one or
more of the disadvantages of the related art.
[0052] Virtual Environments (VE), as discussed herein, can be any
of a Virtual Private Server, a Virtual Machine, a Hypervisor-based
Virtual Machine, and a Lightweight Hypervisor-based Virtual
Machine, a session of Terminal Server Windows 2003 (or older) and a
session of Citrix Presentation Server, Lightweight Hypervisor-based
Virtual Machines, VMM-based VMs or hypervisor-based VMs. Each VE
provides a set of services to local and remote users. A Virtual
Environment, such as, for example, Virtual Machine (VM) or Virtual
Private Server (VPS) is a type of an isolated Virtual Environments
that run on the same physical machine simultaneously. Each VM/VPS
instance accesses its own files, as well as files used by other
VMs/VPSs.
[0053] In particular, the embodiment includes the use of links,
pointers or stub files to allow multiple users to access a common
system file tree, including files relating to the operating system
configuration and user services. The links show a path to a
location of files of the common system file tree, the pointers
directly point to the actual files of the common system file tree
and the stub files store some information that refers to the files
of the common system file tree or the files on network storage. In
order to access some files, the corresponding stub files need to be
accessed and read first. Then using the referral information form
the stub files the corresponding files can be accessed.
Accordingly, every user can modify his files, independent of the
access time and the presence or absence of other users, such that
the modifications are only visible to the user who changes the
file.
[0054] From the point of view of the preferred embodiment of the
invention the stub files and the links are functionally equivalent.
Usage stub or links depends on partial file system properties
and/or available virtualization means. Links and stubs support the
ability to get an access to the required object, e.g., file or
folder of the common file tree or the object on network storage or
on other storage means. Herein the term "file" may mean the file
itself or other objects referenced by stub or links or other
redirection means as well. In partial embodiment, the link files
may be ordinary files of the file system containing access path for
the object to which the link file points. In some embodiments of
the invention the stub file may be zero sized file. In some
embodiments of the invention, the stub files may just indicate by
the content of stub file, by flags in the stub file properties or
by other mechanisms such as watermark in the content or in the
filename that the real object is stored in the shared area. For
this purpose the stub files may or may not contain ID of the
corresponding object, where path to the object itself may be
contained in the database and corresponds to the ID. Herein the ID
may be filename of the stub file or ID may be stored as the stub
file content.
[0055] Furthermore as directories or folders or similar objects may
be discussed as a file of certain type with requisites indicating
that the file is a directory, the stub files or the link files may
represents directories and point to directories as well.
[0056] Some partial embodiments of realization the stub files, the
link files and methods and systems for treating these files are
discussed in U.S. patent applications application Ser. No.
10/691,066, filed Oct. 21, 2003, entitled "System And Method For
Providing Effective File-Sharing In A Computer System To Allow
Concurrent Multi-User Access," which is a continuation of
co-pending application Ser. No. 10/401,636, filed Mar. 27, 2003
entitled "System and Method for Providing Effective File Sharing in
a Computer System to Allow Concurrent Multi-User Access," which
claims priority to provisional patent application Ser. No.
60/367,951, filed Mar. 27, 2002 and entitled "Method of Using Links
to Let Different Users Share a File Tree," and Ser. No. 11/779,258
filed on Jul. 17, 2007, entitled "Effective File Sharing Among
Virtual Environments," incorporated here as a reference.
[0057] Physical users can generally be of two types, remote users
and local users. In case of Virtual Environment (VE), for example,
Virtual Private Server (VPS), the users are usually remote users of
the server. However, these users can be local users of a computer
system. Each physical user has a user ID, which is associated with
a set of processes and permissions to access files. Multiple
physical users (both local and remote) can be simultaneously logged
into a VE (or an OS of a computer) and share files residing on the
physical machine, where the VE is executed. In one of the
embodiments, a method for sharing common files among multiple VEs,
is provided. Each VE can have multiple physical users who
indirectly access sharable common files.
[0058] In one embodiment, a plurality of VEEs running on a computer
system is provided. The computer system has a common file system
tree, which can be concurrently accessed by the VEEs. The shareable
files are stored in the common file system tree located in a local
storage of the computer system. The common file system tree
includes a first set of files that can be accessed by VEEs directly
using one redirection. The common file system tree also includes a
second set of files that can be accessed by VEEs using first and
second redirection. The files system accesses the files from the
local storage using first redirection and from the network storage
using a second redirection. The local storage can also receive
files from the network storage and store them in the common file
system tree. This approach provides a file system that is not
solely based on the local storage. Keeping essential file templates
on the network storage allows for more efficient migration of the
VEEs.
[0059] The file management system according to the preferred
embodiment operates in a following manner. Each VEE activated in
the computer system has its own allocated virtual memory. Local
storage has a file system (for each VEE) that includes stub files
containing references to the common template file system tree. The
common template file system tree, in turn, has stub files
containing references to the files in the templates on the remote
network storage. The files from the templates on the network
storage referenced by stub files of the common template file system
are loaded into the common file system. Then the files from the
common files system that are referenced by the stub files of the
VEE file system are loaded into the VEE file system, and are then
provided to the respective VEE via system I/O means. The files are
loaded and cached according to predefined rules.
[0060] A file management method, according to the preferred
embodiment, includes activating a plurality of VEEs on a computer
system and creating a file system tree containing descriptions of
all files required for each VEE running on the computer system. A
common template file system tree that can be concurrently accessed
by the VEEs is also created. The file system tree and the common
template file system tree are stored in local storage of the
computer system. The files (i.e. files containing a metadata with
reference to another file) are copied from the common template file
system tree to the local file system tree. The stub files to the
common template file system tree from the local file system tree
are created. Then the stub files to the common template file system
tree from the VEE files system tree and the stub files to the
network storage from the common template file system tree are
created. When one of the VEEs attempts to access a file from the
network storage via VEE file system using second redirection, the
file is loaded from the network storage to the local storage and
file access is provided using the first redirection.
[0061] As discussed above, one embodiment of the present invention
is directed to a system and method for accessing a common file
system associated with a computer system that provides for
multi-user access. FIG. 1 illustrates an exemplary embodiment of
the computer system of the present invention, indicated generally
at 100, and user access thereto. Computer system 100 includes a
shared file tree 125 that is associated with the files that may be
shared or accessed by the users of computer system 100. Computer
system 100 allows for multiple users 115a-c, referred to as Users
1, 2 and 3, respectively.
[0062] Although three users are depicted in FIG. 1, it should be
understood that computer system 100 can be configured to
accommodate more users. Each user 115 has access to the shareable
file tree 125. Accordingly, each user can share the file tree 125
to provide multi-user access of the file system of computer system
100.
[0063] In addition, each user 115 is associated with a user file
tree 120. Each user 115 can access shareable file tree 135 via its
own copy of user file tree 120. From the user's point of view, user
file tree 120 is transparent and tracks the structure of shareable
file tree 125, as discussed below. As a result, user file tree 120
allows each user 115 to access files located in shareable file tree
125, including files relating to operating system configuration and
user services. Each user file tree 120 is private and preferably
may not be accessed by other users without administrative
privileges.
[0064] Accordingly, as discussed below, every user 115 is able to
modify his files independent of the other users. As a result, any
user 115 is able to access and modify a file regardless of when
other users are present on the system or access the file. These
modifications to a file are only visible to the user that authored
the changes. For example, as shown in FIG. 1, the file entitled
"myfile," shown at 130, has a file path "/usr/bin/myfile" on
shareable file tree 125. If User 1, shown at 115a, accesses myfile
130 via file path /usr/bin/myfile and modifies this file 130, then
the other users, e.g., users 115b and 115c, that access myfile 130
via this same path, e.g., /usr/bin/myfile, only see the original,
unchanged file 130.
[0065] The modified file, shown at 135, is only visible to the user
that authored the modified file, e.g., User 1, and may only be
accessed via file tree 120 of User 1. Similarly, other files that
have not been changed will be visible to all users in its original
form. For example, "anotherfile," shown at 140, has not been
modified by User 1. Accordingly, all users 115 that access the file
via the file path 1usr/bin/anotherfile will access the file from
shareable file tree 125 and view the same, unaltered, file. As a
result, multiple users may access and modify shared files without
the risk of corrupting the original files.
[0066] In conventional multi-user computer systems, restricting
access to modified files to the author is generally implemented
through directly copying the file system tree for each user. But
this solution requires a great deal of overhead to accommodate
multiple copies of the same files for each different user. As a
result, this conventional solution is not always possible or
efficient due to the additional storage and processing requirements
and the adverse effect on system performance.
[0067] In contrast, as discussed below, the present invention
utilizes specific link files or pointers to provide multi-user
access while minimizing the risk of file corruption. Generally, as
discussed above, a link is a specific file type that serves as a
reference to other files. Accordingly, upon receiving a request,
the link or reference file readdresses the request to another file.
Thus, when a link is accessed, the link itself is not opened, but
rather, the file the link refers to is opened. Thus, the
intermediate data structure in a link may contain data referring to
other files that were not requested. For instance, the intermediate
data structure may contain the path to another file that will be
found and opened instead of this reference link.
[0068] For example, in reference to FIG. 2, "myfile" 210, located
at path /usr/bin/myfile in file tree 200, is a link file that
points to "anotherfile" 215. Accordingly, if user process 220
attempts to open myfile 210, the process will instead open
anotherfile 215. The operation of a link file is generally
transparent to the user. Thus, a user will not be able to determine
that the file is in fact a link file, rather than the actual file
the user is attempting to open, absent a specific request, if at
all.
[0069] FIG. 3 shows an exemplary embodiment of the computer system
of the present invention, shown generally at 100. As discussed
above, computer system 100 includes a shareable file tree,
indicated at 310. In addition, computer system 100 allows multiple
users, shown at 320, to access shareable file tree 310. The
multi-user mode of computer system 100 may generally allow the
operating system processes of different users to operate
simultaneously. Each process within the operating system is usually
associated with information that identifies the user (i.e. user
ID). When accessing a file, the operating system defines the user
requesting the file operation and determines whether the operation
is permitted for that user.
[0070] Generally, this determination may be made upon opening the
file, e.g., requesting a function of the type "open." Thus, on the
basis of this access information, the operating system may organize
different views of the same file system tree based upon selected
parameters, such as, for example, time, operation type or user
information.
[0071] Each user 320 that has access to the computer system's
shareable file tree 310 also has its own user file tree 330 that
contains a directory structure analogous to the shareable file tree
310. But instead of containing a copy of the actual file residing
in shareable file tree 310, user file tree 330 contains a link to
the corresponding actual file in shareable file tree 310. For
example, initially, files 335a and 340b are not copies of the
analogous files in shareable file tree 310, files 345 and 350,
respectively. Instead, files 335 and 340 are link files to actual
files 345 and 350.
[0072] Accordingly, each user 320 accesses the actual file through
its user file tree 330, which, in turn, links to the actual file in
the shareable area. From the user's point of view, this operation
is implemented transparently--the user 320 cannot see the location
to which the link or pointer is directed when it addresses a file.
In an alternate exemplary embodiment, the user may discover the
actual address of the actual file or link only if such feature is
specifically provided by the operating system.
[0073] FIG. 4 shows another exemplary embodiment of the present
invention. Computer system 100 includes a shareable file tree 310.
Shareable file tree 310 includes several shareable files, including
"anotherfile" 345 and "myfile" 350. System 100 also includes a user
file area 410. Each user 320 has access to his own user file tree
330 that may be located in user file area 410. As discussed above,
user file tree 330 contains files that correspond to files in
shareable file tree 310. Accordingly, user file tree 330 includes
"anotherfile" 335 and "myfile" 340 that correspond to files 345 and
350 in shareable file tree 310, respectively. However, user file
tree 330 does not contain copies of the corresponding files in
shareable file tree 310, it only contains links. Accordingly, until
the user attempts to modify the files, as discussed below, files
335 and 340 are initially links to actual files 345 and 350.
[0074] Generally, all file operations may be subdivided into two
categories: (1) operations that modify the file content or its
associated data; and (2) all other operations, e.g., operations
that only access the file. If the user process 320 does not request
a file operation that modifies the file contents of a file located
in shareable file tree 310, system 300 unconditionally opens the
file pointed to by the link. For example, as shown in FIG. 4, user
310 can request to access, and not modify, anotherfile 345. As
shown by Path 2, indicated at 375, user 310 will open anotherfile
335, the link to the actual anotherfile 345, and be permitted to
access this actual file 345. Further operations with anotherfile
345 may be subsequently performed as usual.
[0075] On the other hand, if the user operation attempts a
modification of any information parameters associated with the
file, e.g., its content or length, then system 300 first defines
the link points, e.g., to the original file in shareable file tree
310, or elsewhere. In order to allow users to modify file system
data, each user receives its own private file area, indicated at
370 in FIG. 4 that may be located in the user file area 410.
[0076] Private file area 370 may be a selected memory or storage
location in or accessible to system 300. In the event that a user
320 wishes to perform an operation that modifies a shareable file
in shareable file tree 310 for which the user's file tree 330
contains a link that points to this shareable file, system 300
first copies the shareable file into the user's private file area
370.
[0077] Next, system 100 modifies user file tree 330 so that the
link associated with the shareable file no longer points to the
location in shareable file tree 310, but instead points to the
location of its copy in user's private file area 370. Thus, system
100 performs a user-transparent operation to allow a user to modify
a shareable file without incurring the risk of sharable file
corruption.
[0078] For example, as shown in FIG. 4, user 320 may wish to access
and modify "myfile" 350 located in shareable file tree 310. Because
user 320 wishes to modify the file, system 100 will not allow user
320 to directly access and modify the actual shareable file 350.
Instead, system 100 will copy the shareable myfile 350 to the user
private file area 370. As a result, private file area 370 now
contains a copy of the original shareable myfile, shown at 360.
[0079] Next, system 100 modifies the associated link file, "myfile"
340, located in user file tree 330, to point to copy 360 instead of
the original file 350 located in shareable file tree 310. As shown
by Path 1, indicated at 380, instead of accessing the original
file, user 320 will instead access the link file 340 to open the
copy 360 stored in the user's own private file area 370. User 320
is now free to modify copy 360 as usual. Any modifications made to
this copy 360 of myfile 350 by this user will not be viewable to
other users of system 100.
[0080] Note that private file area 370 and user file tree 330 may
be configured to be accessible to a selected set of users, e.g. a
group of users associated with the underlying operating system,
rater than just a single user. Note that user 320 may place files
into private file area 370 that do not contain links, e.g.,
pointers to shareable file tree 310. Moreover, user file tree 330
may contain metadata to optimize user access. For example, the
links located in user file tree 330 may contain metadata concerning
the user's access to the corresponding shareable file. For example,
the metadata may allow a user to define permission to files stored
in the shareable file tree without copying the files into the
private file area 370.
[0081] If the link file in user file area 330 already points to a
file copy in private file area 370, then the operation will be
performed on the copy without any change in user file tree 330. For
instance, if user 320 wishes to continue modifying myfile copy 360,
as discussed in the above example, then user 320 will access myfile
copy 360 via myfile link 340, as shown by Path 1, indicated at 380.
Therefore, any further operations with myfile copy 360 will also be
transparent to user 320.
[0082] User 320 may also freely create new files within system 100.
If a user 320 requests the creation of a new file, the new file
will be created only in the specific private file area 370 or 410.
For example, in the exemplary embodiment shown in FIG. 4, user 320,
e.g., User 1, wishes to create a new file, e.g., a file not present
in shareable file tree 310, entitled "newfile." System 100
preferably allows the user to create this new file, shown as
newfile in 410, only in the user's own data area associated with
user file tree 330.
[0083] Accordingly, user 320 can directly access newfile 355, e.g.,
via file path 1usr/bin/newfile, as shown by Path 3, indicated at
390. Thus, in a preferred exemplary embodiment, only the user that
authored the new file may access or view the new file. In this
example, newfile 355 is preferably not viewable to any other user,
except User 1. In an alternative embodiment, system 100 can create
the new file in the user private file area 370 and modify user file
tree 330 to include a link file that points to the new file in user
private file area 370. User 320 may now access the new file via the
associated link in user file tree 330.
[0084] User 320 can also delete files within system 100. If the
user requests an operation to delete a file that has a link
pointing to the shareable data area, then only the pointer will be
deleted. The original file and its associated data will be
unaffected and accessible by other users. For example, in the
exemplary embodiment shown in FIG. 4, user 320, e.g., User 1,
wishes to delete the shareable file entitled "nofile" 375 located
in shareable file tree 310. Instead of deleting the shareable file,
system 100 will instead delete the corresponding link file, nofile
365, located in User 1's own file tree 330, as shown by Path 4,
indicated at 400.
[0085] Once the link file 365 has been deleted, User 1 will not be
able to view or access nofile 385, absent intervention by the
system administrator, for example. Accordingly, from User's 1 point
of view, nofile 385 has been deleted, even though it is still
available to all other users. If the user requests deletion of a
file that has a link pointing to a copy located in the user's
private file area 370, then both the pointer itself and the file
copy will be deleted. For example, if User 1 wishes to delete the
modified "myfile" 360, then both the link file 340 and the copy 360
will be deleted.
[0086] If the user requests the deletion of a file that is not a
pointer file and that is located in a specific private data area,
e.g., private file area 370, then that file will be deleted as
usual. As discussed above, a user's decision to delete a file will
not affect another user's existing ability to access a file.
[0087] FIG. 5 illustrates an exemplary embodiment of the method of
the present invention. At step 500, the system receives a user
request to access a file. At step 510, it is determined whether the
requested file is a shareable file located in the shareable file
tree or a private file. If it is determined that the file is a
shareable file, then, at step 515, it is determined whether the
user wishes to delete the file.
[0088] If so, then the link to this file located in the user's file
tree is deleted--not the shareable file--at step 520. Otherwise, it
is determined at step 525 whether the user wishes to modify the
shareable file. If not, then at step 535, the user may access the
shareable file via the user file tree. On the other hand, if the
user wishes to modify the shareable file, then the system copies
the shareable file to the user's private file area, at step 530,
modifies the user file tree to point to this copy, at step 540, and
then allows the user to modify the copy (not the original shareable
file) at step 545.
[0089] If it is determined at step 510 that the user wishes to
access a private file, then it is determined at step 550 whether
the user wishes to delete the private file. If so, the system
deletes both the file copy and any associated pointer file. If the
user merely wishes to modify the file, at step 570, then the system
allows the user to directly modify the private file at step 580. On
the other hand, if the user only wishes to access the file, then at
step 590, the user is allowed to access the private file.
[0090] The system and method of the present invention manages
access such that all modifications made by one user in any file of
the shareable file tree 310 are independent from the actions of
other users and are visible only to the user making the
modifications. As discussed above, file manipulation is implemented
in the operating system by utilizing links in the file system.
Generally, access to files in a file system is provided through
specific intermediate data structures, e.g., inode. These
intermediate data structures contain information associated with
the file, such as, for example, where the file data may be found on
the disk or the time of the last file modification.
[0091] As discussed above, in order to provide this type of access,
the computer system creates two directories for each user: a first
directory to repeat the structure of the shareable tree to store
links to files, e.g., user file tree 330, and a second directory to
store files copied from the common area, e.g., private file area
370. In one exemplary embodiment, these directories are implemented
using a mounting system call that has the required directories as a
parameter. During analysis of the access file path, the system will
determine when the access path passes in the sub-tree accessible
through the mounting point. The appropriate software then controls
access to the files inside the directory.
[0092] Thus, when searching for a file via the access path, an
analysis of the access path is initially provided and the algorithm
determines whether this path intersects any mounting point. If the
path intersects the mounting point of the described file system,
the processing is performed according to the principles described
above.
[0093] Therefore, the algorithm determines the address within its
own private tree of the file system and searches for an
intermediate data structure used to access an object. If the
structure is not found, the file is considered absent. If the
structure is found, then that structure is used to determine the
type of file object, and, depending on this type of file object,
the algorithm either enables operation on the data pointed to with
the file, or provides readdressing to another file, if the file is
a link file. If at least one of those structures is not located,
the file is considered to be absent.
[0094] As discussed above, similar data structures can be created
"on the fly" during interaction with the file system. In this case,
these structures are stored only in the random access memory of a
computer or in its cache, rather than on the hard drive or similar
storage device. For example, those structures created on the fly
may be stored in the temporary buffer data area on the disk or in
RAM, or any other similar memory location.
[0095] In another embodiment a method for sharing common files
among multiple VEEs is provided. VEE users can modify, update,
replace and delete shared files. When a VEE user modifies a shared
file, the system creates a private copy of the file transparently
for the user. Thus, file modification do not affect the other VEE
users.
[0096] An exemplary computer system 100 for sharing common files
among VEEs is illustrated in FIG. 6. The file system having a root
directory 601 is located at a physical level of a computer system
100. Common files 603 are shared by VEE users 602A and 602B. Unlike
a conventional file sharing model, the proposed system does not
allow to access sharable files 603 through the file system root
directory 601, which requires calculating the file path. Instead,
files and directories in a shared area 603 are accessed via links
contained in the files and directories of the VEE user's private
area. The links contained in the files or directories are defined
by a special metadata attribute.
[0097] In the example depicted in FIG. 6, VEE Users 1 and 2 access
files and directories within their own private root directories
602A and 602B. The files and directories of the private root
directories 602A and 602B contain links to files and/or directories
of the shared area 603. The link related metadata attributes 601,
610, 611, 613, 621, 622, 623 within the private files and
directories are illustrated by black squares. For example, when VEE
User 1 accesses the file File 1, the metadata attribute 601
specifies if the file is a data file or a link to a file in the
shared area 603 is read.
[0098] If the file metadata attribute 601 specifies that the file
is a link, the file data portion is not open and the file Fx-1.ext,
to which the link refers to, of the shared area 603, is accessed.
This file can have any type of extension (such as, for example,
".txt", ".exe", ".mpeg", "jpeg," etc. --a genetic extension ".ext"
is used in the figure). Likewise, VEE User 2 can access the file
Fx-2.ext via the link File 2 having metadata attribute 621. The
same access algorithm can be used with file directories. For
example, VEE User 1 can open the directory Dir 1 in the private
root directory 602A and use the link defined by metadata attribute
611 to access the directory Dir 11 in the shared area 603. Note
that links are created, deleted or modified by the file system and
the VEE users are not allowed to create, delete or modify the
links. The VEE users can see the links in the VEE user's root
private area, but user access to actual links and the link metadata
within files or directories is blocked. This arrangement provides
for effective file sharing among VEE users without compromising
integrity and security of the file system.
[0099] Dir 12 and Dir 13 are accessed the same way through the
referring links contained in Dir 2 and Dir 3. Same works for file
Fx-3.ext accessed by VEE User 2 through the corresponding link File
3. Thus, the files and directories are accessed and shared by VEE
users indirectly through links. Note that each file and/or
directory in a VEE user's root private area can have multiple links
to files and/or directories in the common shared area. Directories
in a private VEE area can have links to directories and/or files in
the common shared area, and files in private VEE area can have
links to files and/or directories in the common shared area.
[0100] The link files are files with a special metadata attribute
and they are regular files when seen from hardware point of view.
This arrangement provides for a faster and more efficient VEE back
up and restore process. Significant amounts of RAM and disk space
are saved by the proposed embodiment. The embodiment also provides
for increased security as VEE users have no access to system file
root directory. When VEE users access the files form the shared
area, they are not aware of the actual location of the file since
the file path is hidden within the links. As discussed above, the
VEE users cannot access the metadata contained in the link files.
Thus, VEE back up process remains absolutely unaffected by the
multiple VEE users sharing files and directories.
[0101] In order to provide security and system integrity, it is
preferable that the computer system limit the extent to which users
may mark files, such as creating a specific mark. Generally, the
creation and characteristics of a specific mark depends on the
underlying file system. For example, for a Linux system, a special
file flag, e.g., a "sticky bit" can be used as a specific mark
because this flag is not used by standard file systems for symbolic
links. In other file systems, e.g., Windows NTFS, for example, the
system can use other techniques to mark files.
[0102] A specific mark may be a standard link or pointer of the
underlying file system. For example, a specific mark may be a
symbolic link in a Unix file system. In this case, a user can
create its own symbolic links using standard as interface. These
user-created links are distinguishable from the system's own
pointers. But, if the system allows regular users (and not just
system administrators) to create such links, the user can
accidentally or intentionally create a link pointing to some
critical system files that may compromise system security.
[0103] For instance, the user may create a link to a "/etc/shadow"
file that contains encrypted passwords for the system. Accordingly,
the system should not allow users to mark files accessed via
"mounted" points. Therefore, these links should only be created at
the direct access to the private user area by means of the
underlying file system, and the access path should not contain the
mounting point of the file system being described.
[0104] For example, the system should allow creation marks for
files from "/vz/private" directory tree (see discussion of
Virtuozzo.TM. below regarding the "vz" directories), but should not
allow creation of such marks for files from the "/vz/root"
directory tree.
[0105] Note that in an exemplary embodiment of the present
invention, the chroot function may be used to move root file
systems for a particular user or set of users into predefined
locations and to prevent users from accessing unauthorized sections
of the file system. Usually, the mounting point of the mentioned
file system is used to provide access through utilization of the
chroot primitive, e.g., the procedure of changing the root of the
file system.
[0106] Functioning of the mounting point is based on the principle
of shifting the file system real root or "root" directory to any
selected location. For example, the root directory may be moved to
the mounting point of the file system for a certain group of
processes, such as, for instance, for all processes of a user.
Consequently, all file operations associated with the user
processes within the mentioned file system are handled with the
transparent substitution of files, as discussed above. As a result,
the user then has no opportunity to explicitly create pointer files
having specific marks as interpreted by the file system.
[0107] For example, in a VE, users can be restricted to use only a
mounted tree, rather than the actual underlying file system. In
this case, if the "chroot" function is applied to "/vz/root" for
user processes, users will be unable to create such pointers
because the file system will be accessed using "/vz/root." As
discussed above, this is advantageous from a security point of
view.
[0108] Note that, in one embodiment, the present invention does not
require a mounting system call, but rather, the present invention
may utilize mounting system calls in an exemplary embodiment of the
invention. Moreover, the present invention does not require the
creation of a mounting point when the user modifies a file (and
creates a copy in its private file area). The file system can use a
single mount point to combine two known file trees (such as, for
example, "/vz/private" as a private area and "/vz/template" as a
common shared read-only area) into a new, combined tree (for
example, into "/vz/root" where all files from /vz/template and
/vz/private appear from the user point of view).
[0109] Accordingly, to create such an area, the system may use a
single mount call with these two trees as parameters. After the
creation of this mount point, this combined tree will be usable by
the user, and all access to files using this path (for example, to
file "/vz/root/etc/passwd") will be handled by the file system
driver because the path traverse operation will cross /vz/root/.
All copy-on-write and other link-related operations will be
performed by the file system driver and no additional mount
operations are required.
[0110] To modify the content of the shareable area of the file tree
so that all changes become visible to all users having access to
the area according to the described scheme, it is necessary to
modify the above-mentioned shared tree, create specific links to
the new files for all users of the system having their own private
areas, and delete those links that point to non-existent files. It
may also be necessary to create additional directories in these
private areas.
[0111] For example, to make a change visible, the administrator or
the user itself can call a special procedure that will create such
a link in the user private area. This link will point to the shared
area, and typically it is transparent for the user. The special
procedure may usually create a normal "standard" link on the
underlying file system, and later mark it as a "magic" link using a
special interface implemented by a file system driver or the OS
kernel.
[0112] The embodiment also provides a number of advantages over
prior art file systems that require multiple searches or use system
snapshots and record changes to different sub-trees at different
times, such as MFS (Mirage File System). For example, the proposed
embodiment utilizes links or stub files that allow the system to
conduct a single search. Accordingly, the proposed embodiment
utilizes less system resources, e.g., the proposed embodiment does
not need to cache additional directory entries in a file system
cache to deal with the additional file paths associated with system
snapshots.
[0113] Moreover, the proposed embodiment does not use a full duplex
of the structure of intermediate data structures of the file system
tree and can work with the file system without formal inodes
structures, such as, for example, the Linux journaling file system
called "ReiserFS." Moreover, the proposed embodiment is not limited
to operating at the level of the block data storage and the
algorithms of data distribution on the disk, but, rather, at the
level of files and pointers to those files. As a result, it is
possible to use practically any underlying file system in the
present invention.
[0114] An exemplary system for file management, in accordance with
another embodiment, is illustrated in FIG. 7. The proposed system
advantageously provides access to file templates located on the
network storage, thereby saving computer system resources and
making the system more fault-tolerant. In the exemplary embodiment,
computer system 100 has two VEEs (720A and 720B) running on it.
Note that any number of VEEs can be activated in the computer
system 100. VEE 720A executes user process 722A and VEE 720B
executes user process 722B. The VEEs 720A and 720B have their own
file systems 724A and 724B respectively. The file systems 724A and
724B communicate with their respective virtual storage redirectors
728A and 728B via their respective virtual disc drivers 726A and
726B.
[0115] The virtual storage redirectors 728A and 728B redirect
(using a first redirection) file requests to file system 729
implemented under Host OS 704. The file system can access the file
templates stored in a local storage 731 and send the requested
files directly to VEEs' file systems 724A and 724B via I/O means.
If the requested files are not found in the local storage 731, the
file system 729 redirects the request (using a second redirection)
to a downloading utility 730. The downloading utility 730 has a
local mounting point for the remote network storage 732 and the
requested files can be downloaded into the utility 730 from the
templates located on the network storage 732. Then the downloaded
files are redirected back to the file system 729 and provided to
the respective VEEs' file systems 724A and 724B via system I/O
means. The requested files are also provided to the local storage
731 by the downloading utility 730. Thus, only previously requested
files are being stored locally in local storage 731 and the memory
resources of the computer system 100 can be saved.
[0116] A file management method, according to the preferred
embodiment is illustrated in FIG. 8. The proposed method includes
launching VEEs on a computer system (step 800) and creating a file
system tree containing descriptions of all files required for each
VEE running on the computer system (step 810). A common template
file system tree that can be concurrently accessed by the VEEs is
also created in step 820. The files are copied from the common
template file system tree to the local file system tree in step
830. The stub files containing references to the common template
file system tree from the local file system tree are created in
step 840.
[0117] Then the stub files containing references to the common
template file system tree from the VEE files system tree are
created in step 850 and the stub files containing references to the
network storage from the common template file system tree are
created in step 860. When one of the VEEs attempts to access a file
from the network storage via VEE file system using second
redirection in step 870, the file is loaded from the network
storage to the local storage (step 880) and file access is provided
using the first redirection (step 990).
[0118] FIG. 9A illustrates additional detail of implementation of
the system in accordance with one preferred embodiment. The
exemplary system is illustrated in FIG. 9A using just one VEE 910A
running on the computer system 100. Note that the proposed method
and system can be implemented with any number of VEEs running on
the same computer system 1000, or on a computer cluster. Local
storage 731 has VEE file system 940A that includes stub files 941A
containing references (pointers) to the common template file system
tree 950A.
[0119] The common template file system tree 950A has stub files
951A containing references to the files that can be stored locally
950A or on the network storage 732. The files referenced by stub
files 951A are loaded into the common file system 950A. Then the
files from the common files system 950A that are referenced by the
stub files 941A are loaded into the VEE file system 940A and then
provided to VEE 910A via system I/O means. The files are loaded and
cached according to predefined rules.
[0120] The set of operations that are allowed for files stored
locally 950A or on the network storage 732 (e.g., template files)
are not restricted to the read-only operations. For example, access
time as one parameter, which is a field of the file structure that
is "attached" to the file and that can be modified.
[0121] In FIG. 9B, there are two VEEs 720A and 720B that are
executed on the two different physical machines 930B and 940B.
Thus, the VEEs have their own local storages 731A and 731B. The
VEEs may have a connection to the remote network storage or to
other VEEs, such as using a system area network (SAN), Infiniband
network, TCP/IP network, etc. The network storage 732 contains the
templates that are needed for VEEs functionality. This exemplary
system shows how the VEEs receive the templates that are kept on
the network storage 732 or on the VEEs local storages. In the
preferred embodiment, there are three versions of data access: from
the remote network storage, from the VEE local storage and a
combination of the two.
[0122] FIG. 9B shows three templates in the network storage:
template 732A, template 732B and template 732C. The local storages
731A and 731B have VEE file systems 932B and 942B. The stub files
933B and 943B that are located in the VEE private file system hold
the references to the common template file system trees 934B and
944B. The first VEE 720A has only one template 2 that corresponds
to the template 732A in the network storage. The first VEE 720A
needs two templates: template 1 that is contained on the second VEE
720B and template 4 that corresponds to the template 732C in the
network storage 732. A similar situation exists for the second VEE.
The second VEE has the template 1 however the template 732A and
template 732B are required for the implementation of this VEE.
[0123] Thus, the VEEs' file access requests are redirected to file
systems 932B and 942B. The file system using stub files verifies
the location of the required templates. The file requests allow
getting to the common file system tree. The references (redirects)
of the stub files 935B and 945B that are used by the common file
system tree 934B and 944B contain files that may be stored locally
or on the remote network storage 732.
[0124] Two VEEs simultaneously may get the same templates that are
located on the network storage 732 based on their requests. Also,
the stub files may have files stored on the local storages of other
VEEs. In this case, the first VEE 720A can extract the template 1
from the physical machine 930B. Then, the second VEE 720B that is
contains the required template will be another network storage for
the first VEE 720A. The requested templates can be loaded and
supplied to the VEEs.
[0125] FIG. 9C illustrates the method of VEE data migration,
according to the preferred embodiment. The network storage 732
contains the VEEs templates that can be used for the deployment and
updating the VEEs. FIG. 9C shows the VEE data migration for the
purpose of deployment new VEE on the any physical machine. There
are two templates on the network storage 732: template 732A and
template 732B. In this exemplary system, the template 2 and
template 3 are located on the physical machine 930B. In this case,
the template 1 corresponds to the template 732A in the network
storage 732 and, similar to template 1, template 2 corresponds to
the template 732B.
[0126] Thus, if there is a need to implement the VEE 720A on this
machine, two of the required templates already exist. The missing
template 732A can be downloaded from the remote network storage
732. This template can be obtained using the method described
earlier. If there is a need to migrate the VEE 720A from one
physical machine 930B to another physical machine 940B, then
template downloading of the VEE 720A is not required. The missing
templates can be immediately migrated from the network storage 732
and from the first physical machine 930B to the new physical
machine 940B. In this case, the template 2 already exists on the
second physical machine 940B, the template 1 will be copied from
the network storage 732 and the template 3 will be downloaded from
the first physical machine 930B.
[0127] The data access may be provided during VEE creation and
during VEE startup in different ways. In one of the embodiments,
during VEE creation, templates required for starting VEE may be
provided locally. When all the required templates are accessible,
the VEE may be started. On the other hand, startup of the VEE
requires stubs or links to template files and the file itself may
be unavailable during startup.
[0128] In some cases there is a need for template migration when an
existing VEE is migrated, e.g. the VEE is migrated from one
physical server to another. Here, using stub files or links, the
required templates will be migrated from the network storage or
local storage. In some embodiments of the invention, the common
file system tree may use not only the mechanism of stub files
and/or links for getting of necessary data but upon request for
certain template from a user, entire folders can be copied.
[0129] Another option of the VEE data migration is getting required
files during VEE startup. In this case, VEE data migration also may
be implemented on an "on-demand" basis by migration of entire
files. Also, the data migration may copy files and/or portions of
files that are required during VEE execution, e.g., when there is
an attempt to open file or to access any template file. The
migration of portions of files is discussed in U.S. Pat. No.
5,813,008, incorporated herein by reference, which assigned to
Microsoft Corporation, and which describes Single Instance Storage
SIS.
[0130] Also, during "on-demand migration," all remaining data may
be migrated as a background process.
[0131] Offline and online migration processes that may be used here
simultaneously with the proposed data migration, e.g., for
background data synchronization. Thus, these processes can be
migrated in parallel and/or sequentially and in a particular order
chosen based on the assigned tasks. U.S. patent application Ser.
No. 10/837,618, filed on May 4, 2004, entitled SYSTEM, COMPUTER
PROGRAM PRODUCT AND METHOD FOR ONLINE DATA MIGRATION WITH MINIMAL
DOWN-TIME describes the minimization of the down-time during
migration process, and is incorporated by reference. This is done
by freezing all processes on the source server and migrating the
required data from the source server to the target server.
[0132] With reference to FIG. 10, an exemplary system for
implementing the invention includes a general purpose computing
device in the form of a computer or server 100 or the like,
including a processing unit 21, a system memory 22, and a system
bus 23 that couples various system components including the system
memory to the processing unit 21. The system bus 23 may be any of
several types of bus structures including a memory bus or memory
controller, a peripheral bus, and a local bus using any of a
variety of bus architectures.
[0133] The system memory includes read-only memory (ROM) 24 and
random access memory (RAM) 25. A basic input/output system 26
(BIOS), containing the basic routines that help to transfer
information between elements within the computer 100, such as
during start-up, is stored in ROM 24. The computer 100 may further
include a hard disk drive 27 for reading from and writing to a hard
disk, not shown, a magnetic disk drive 28 for reading from or
writing to a removable magnetic disk 29, and an optical disk drive
30 for reading from or writing to a removable optical disk 31 such
as a CD-ROM, DVD-ROM or other optical media.
[0134] The hard disk drive 27, magnetic disk drive 28, and optical
disk drive 30 are connected to the system bus 23 by a hard disk
drive interface 32, a magnetic disk drive interface 33, and an
optical drive interface 34, respectively. The drives and their
associated computer-readable media provide non-volatile storage of
computer readable instructions, data structures, program modules
and other data for the computer 100. Although the exemplary
environment described herein employs a hard disk, a removable
magnetic disk 29 and a removable optical disk 31, it should be
appreciated by those skilled in the art that other types of
computer readable media that can store data that is accessible by a
computer, such as magnetic cassettes, flash memory cards, digital
video disks, Bernoulli cartridges, random access memories (RAMs),
read-only memories (ROMs) and the like may also be used in the
exemplary operating environment.
[0135] A number of program modules may be stored on the hard disk,
magnetic disk 29, optical disk 31, ROM 24 or RAM 25, including an
operating system 35 (preferably Windows.TM. 2000). The computer 100
includes a file system 36 associated with or included within the
operating system 35, such as the Windows NT.TM. File System (NTFS),
one or more application programs 37, other program modules 38 and
program data 39. A user may enter commands and information into the
personal computer 100 through input devices such as a keyboard 40
and pointing device 42. Other input devices (not shown) may include
a microphone, joystick, game pad, satellite dish, scanner or the
like. These and other input devices are often connected to the
processing unit 21 through a serial port interface 46 that is
coupled to the system bus, but may be connected by other
interfaces, such as a parallel port, game port or universal serial
bus (USB). A monitor 47 or other type of display device is also
connected to the system bus 23 via an interface, such as a video
adapter 48. In addition to the monitor 47, personal computers
typically include other peripheral output devices (not shown), such
as speakers and printers.
[0136] When used in a LAN networking environment, the personal
computer 100 is connected to the local network 51 through a network
interface or adapter 53. When used in a WAN networking environment,
the personal computer 20 typically includes a modem 54 or other
means for establishing communications over the wide area network
52, such as the Internet. The modem 54, which may be internal or
external, is connected to the system bus 23 via the serial port
interface 46. In a networked environment, program modules depicted
relative to the personal computer 100, or portions thereof, may be
stored in the remote memory storage device. It will be appreciated
that the network connections shown are exemplary and other means of
establishing a communications link between the computers may be
used.
[0137] Having thus described a preferred embodiment of a system and
method for providing file-sharing in a computer system to allow
multi-user access, it should be apparent to those skilled in the
art that certain advantages of the described method and apparatus
have been achieved. In particular, it should be appreciated by
those skilled in the art that system and method described in the
preferred embodiment provide for a faster and more efficient
management of a computer file system that allows file sharing among
VEEs. Those skilled in the art would also appreciate that a
proposed method for file management significantly increases an
overall fault-tolerance of a computer system.
[0138] It should also be appreciated that various modifications,
adaptations, and alternative embodiments thereof may be made within
the scope and spirit of the present invention. The invention is
further defined by the following claims.
* * * * *