Re: Extreme fragmentation when writing large bkf files to compressed drive

sees this file as having 151,238 fragments.

In the graphical representation does it still show one contiguous block occupied by the file?

When NTFS compresses a file it divides the uncompressed data into units of 16 clusters. If its able to compress it by more than one cluster it compresses it, otherwise it is left uncompressed. Due to this method of division NTFS may record each 16 cluster units as individual "runs"*. Defrag utilties frequently queries for number of runs in a given file to determine the number of fragments in the file. In case of normal files if NTFS finds a contiguous free space big enough for the file it will allocate it in a single run. With the compressed files, however, even if it finds contiguous space it will record these chunks as runs. These runs may be right next to each other but defrag utilties may consider them to be fragments. In my opinion future versions of defrag utility should consider not reporting file as fragmented if runs themselves are contiguous.

The delete time you mention below looks extreme to me and I dont have a good explaination as to why it may take that long. If I come across it I will let you know.

Also note: Depending upon yor cluster size you may be approaching the limitation on compressed file size. It is between 30GB to 69 GB.

*run: Extent. Read more on NTFS disk structure.
--
This posting is provided "AS IS" with no warranties, and confers no rights. OR if you wish to include a script sample in your post please add "Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm";



"Frank B Denman" <news@xxxxxxxxxxxxxxxxxx> wrote in message news:a16sh25j8chpu0252h4h41uvfrv878uvru@xxxxxxxxxx
Hi Folks,

I'm experimenting with using NTFS compression when backing up across the network
to a USB2.0 drive on a workstation. Backup software is the native ntbackup, the
uncompressed bkf files are around 38GB, the USB drive is 250GB. Ntbackup is
running on a Win2k SP4 server, and the USB drive is on a WinXPP SP2 machine.

Just to verify that compression was working, I copied an existing 16.8GB bkf
file to the empty compressed USB drive, where its size on disk was 14.1GB. Disk
Defragmenter sees the copied bkf file as having 2,587 fragments.

Next, I ran a backup across the network to the same compressed USB drive. The
result is a 37.9GB bkf file whose size on disk is 29.2GB. Disk Defragmenter
sees this file as having 151,238 fragments.

Merely deleting a file like this takes 10-20 minutes of maxed-out cpu.

So I'm wondering whether this is expected behavior with large files and NTFS
compression?

Thanks

Frank
Frank Denman
Denman Systems
news@xxxxxxxxxxxxxxxxxx
[Please delete the "x" from my email address]

.

Relevant Pages

  • Re: Fat32 vs NTFS ?
    ... With NTFS, the data is distributed around the drive, meaning that if you ... or sequentially across the disk. ... Because the fragmentation map doesn't look as pretty, ... If compression was disabled, the drive would have had to read 4GB, ...
    (microsoft.public.windowsxp.general)
  • Re: Oh no, my code is being published ... help!
    ... Please check your hard disk partition is NTFS or FAT32 if it is FAT32 ... Lets say, for example that you have, as I do, a large directory tree ... Both 7sqz and 7usqz use p7zip for the actual compression, ...
    (comp.lang.python)
  • Re: File Compression (native NTFS) - help settle an argument
    ... "While NTFS file system compression can save disk space, ... more noticeable on servers, which are frequently processor-bound. ... loaded servers with a lot of write traffic are poor candidates for data ...
    (microsoft.public.windows.server.general)
  • Re: How much performance loss when compressing Windows (XP) folder?
    ... NTFS compression will happen in the background and in this case - it probably wouldn't amount to much gain or performance loss. ... You aren't compressing system files in this case - but files you are purposely storing and transporting on the USB thumb drive. ... NTFS can conflict with 3rd party apps that also use compression, specifically apps that have a database to hold their data, which can get large and will often enploy some type of compression. ...
    (microsoft.public.windowsxp.general)
  • Re: Defrag Anomoly
    ... The native NTFS file compression is 100% reliable. ... > empty and that's when I actually ran defrag. ... > used to use that back in the old DOS days when hard disk space ... >> The volume lacks adequate contiguous free space to defragment all files. ...
    (microsoft.public.windowsxp.basics)
Quantcast