Problem description:
Under certain circumstances applications and utilities may fail with one (or more) of the following symptoms
- Error 0x80070299
- The requested operation could not be completed due to a file system limitation
- Insufficient system resources exist to complete the requested service
Which particular circumstances?
- Large NTFS volumes. It is relatively difficult to get the issue on a 200MB volume, rather easier to get the issue on a 2TB volume
- Heavy fragmentation. The following functions may contribute to heavy fragmentation
- Compression (for old-style LVM disks) or data deduplication (For Storage Spaces volumes)
- Sparse files
- Certain utilities appear to create susceptible space allocation patterns. Personally I get it mainly on SQL backups and restores. It is also reported against Exchange Server backups and restores and Window backups
How can the issue be addressed?
-
MS KB article 967351 was originally taken to address this issue. Although it is not clear from the KB article the change to the FORMAT utility has been rolled forward into subsequent Windows levels. The give-away is addition of the /L parameter to the FORMAT utility. Apparently what the fix code does is increase the number of Attribute List entries that can be associated with a file, in effect allowing additional fragmentation before the problem occurs
-
Defragmentation. Windows as standard does volume defragmentation on a regular basis; it is scheduled through the Windows Task Scheduler. Files that are more at risk are those
- that are written between defragmentation runs with sufficient fragmentation to trigger the problem. Backups appear to be a prime example. Fresh deduplication (or compression) of a full volume may potentially also trigger this
- files that are constantly open, like SQL or Exchange databases. Files that are always open will not be available for defragmentation
How do I know the volume has been formatted with /L parameter?
Not clear; there does not appear to be a consistent difference in the file system information as displayed by FSUTIL command or BIOS Parameter Block
Can the format parameters size be changed retrospectively?
Probably not; the only known interface is from the FORMAT command, which will in turn delete the volume information and all it's data. In practice what I have done in a virtualised environment is to create a separate .vhdx file, format it appropriately, and bulk-copy the data (using a utility like robocopy) from the existing volume to the new volume. As I understand it Windows Backup/Restore will not do the trick; on restore it will preserve the previous format parameters
What would I recommend?
- Formatting volumes that will be used for SQL or Exchange or Windows backups with the /L parameter
- Formatting Storage Spaces volumes that will be set for data deduplication, or LVM volumes that will be set for compression, with the /L parameter