Data Storage and Management
Data Storage and Management |
|
The unnamed data attribute of an NTFS file has the information being tracked by NTFS that is needed to manage the data. The modification time, logical size, physical size, and access time of the file are all kept relative to the unnamed data attribute. The modification time and logical file size are never changed for the file even when it is a placeholder.
The file is recalled if necessary on the first read, write, or memory map request. If the data is in remote storage but is not in the library, the recall does not succeed. Automatic recall of data that is not in the library is not available and fails with the message STATUS_FILE_IS_OFFLINE. The administrator needs to manually insert the media into the library and then try the recall again.
If a request is made against a premigrated file, it is not affected by Remote Storage. The data for the file exists locally on the NTFS volume and is accessed normally.
The client making the request on the server might time out. Client computers have their own configured time-out which is independent of Remote Storage, and if recalling the data takes longer than the time-out, the input/output request fails on the client. In Windows 2000, the time-out for accessing off-line Remote Storage files is 15 minutes.
Note
Changing attributes or ACLs or named streams in a file does not recall the file.
By default, when a placeholder is opened on an NTFS volume, the data is copied directly from remote storage to local storage and the file is considered a premigrated file. The last access time of the file is changed. Specific error cases arise because of the state of the system or the location of the data in remote storage. When the data cannot be brought back to local storage, the open request always fails with the message STATUS_FILE_IS_OFFLINE.
The FILE_FLAG_OPEN_NO_RECALL flag is honored if the file is opened for read access only, or if the open fails.
If the open request is made with the FILE_FLAG_OPEN_NO_RECALL flag the data is recalled at read time, cached, and placed directly into the application's read buffer. This allows backup systems to get an image of the file that appears (and restores) as a premigrated file but that was not recalled by the backup application.
Note
The migrated data appears only briefly and is not actually copied to local disk storage.
Runaway recalls can be prevented by specifying that no more than a certain number of files can be recalled by a user from a volume in an hour. This is an administrator-defined setting, both in terms of enabling or disabling the feature, and in specifying the number of recall requests that are handled in a particular period of time.
Administrators can select exemption from any recall limit.
No action is taken upon the deletion of a placeholder or premigrated file. It is not possible to synchronously determine when a file is going to be deleted.
Files cannot be renamed across volume boundaries. Placeholders and premigrated files can be renamed only on the same volume. Renaming a file does not cause the data in remote storage to be recalled. Truncation and recall of these files are not affected.
Copying or moving placeholders between volumes causes the data to be recalled and the entire file, including all migrated data, is copied. At the end of a move operation the original placeholder file is deleted. Copying a file has the same behavior within a volume or across volumes. Moving placeholders on the same volume is a rename operation.
A placeholder can be moved to another volume within the same system by using Backup to back up and restore the placeholder to another volume. In this case, the moved placeholder points to remote storage and is valid to initiate a recall. A user-defined action to validate placeholders corrects any potential inconsistencies between the placeholder and remote storage. Even without the validation of a placeholder, opening the moved placeholder recalls the correct data; however, a volume decommission does not work properly.
Table 2.11 summarizes the results of the specific actions when the destination of the action is the same or a different volume.
Table 2.11 Results of Premigrated File Actions
| Action | Destination Same Volume | Destination Different Volume |
|---|---|---|
| Copy File | Recall | Recall |
| Cut File | Recall and delete original | Recall and delete original |
| Move File | No Recall (is a Rename) | Recall and delete original |
| Rename File | No Recall | N/A |
When a managed volume is decommissioned, the physical volume is not accessible. All information needed to decommission the volume is already known. Any data associated with the volume that is in remote storage is treated as available during space reclamation.
If placeholders are moved between volumes, the placeholders must be validated so that correct volume information is known about the placeholders. If the placeholders have not been validated, the volume decommissioning can cause incorrect data within remote storage to be treated as available during space reclamation. For more information about validating volumes, see "Local Storage Management" earlier in this chapter.
A primary storage backup application, such as Backup, protects placeholders. If the placeholder is deleted, lost, or destroyed the only recourse is to retrieve a copy from the backup media. This is the same mechanism that must be used if any other file on the volume is deleted, lost, or destroyed.
The data in remote storage is accessible only through a placeholder. If the placeholder is deleted, that data is inaccessible. If a placeholder is restored from backup, the placeholder is reconnected to that data.
Disconnected placeholders are placeholders whose file contents have been removed from remote storage. These placeholders might have been restored from backup after the space in remote storage was reclaimed or the data within remote storage might be physically unavailable because of media failures. Disconnected placeholders do not point to valid locations in remote storage and are cleaned up by validating placeholders. If the placeholders are disconnected, they are removed from the system to synchronize the remaining placeholders with remote storage.
Volume mount points and symbolic links cannot be changed into placeholders. The system explicitly ignores these types of files.
Any file system scan that encounters a mount point or symbolic link does not follow the link: physical volume space is the scarce resource and mount points and symbolic links are virtual concepts that extend the directory view.
Placeholders identify the specific remote storage system which contains the managed data, tying a placeholder to a specific Remote Storage Engine. Placeholders cannot be moved between multiple remote storage systems.
Remote Storage supports NTFS security features. Remote Storage only recalls files if the user has valid access to a placeholder. A placeholder is identified as a special remote storage reparse point. The security of the placeholder is determined by the security of the reparse point mechanism.
Administrators and regular users go through normal Windows 2000 user security checks. The Remote Storage Administrative user interface uses Windows 2000 permissions to grant or deny access to the user interface. Only user accounts in the Administrators group are allowed access to the user interface functions.
Files are grouped together by their volume and by the time that they were originally premigrated. The files remain grouped during all remote storage operations. No other grouping of files is supported.
Files that are being replicated can be excluded from the Manage Files action by the administrator using the file selection criteria.