Depends a lot on the kind of data you want to be compressed.

Some file formats won't compress at all or hardly: MP3, ISO and so on. Other formats like BMP or ACF/ENV (X-Plane aircrafts and sceneries, which are text-based) will be compressed by 50%. As a rule of thumb, NTFS compression won't work for files that are already compressed in some way of another.

I already guessed that, but it wouldn't hurt to leave it enabled, would it? 😕

Indeed, on the fly compression and decompression are fast enough. But if you need to compress a hard drive that is already full, you should leave your system on and plan a trek across Bhutan in the meantime.

I feel your pain. It took about 1 hour and a half for compressing my work's tiny 38GB drive, which is half-empty by the way.
On the other hand, NTFS compression seems to be transparent enough and only has a little performance hit. 😎

I us NTFS compression on all of my external drives. Does good for .txt,.pst, and CD Image files. Files that are already compressed do not get reduced in size using NTFS compression. Also NTFS compression isn't that good. So if you have files that you can compress using .rar or 7zip...then do so. Don't rely only on NTFS compression to save space you still must clean up and delete files and use real compression.

I use it for small files that I don't modify very often, such as my collection of bink/smacker/miles DLLs: Miles Sound System and why Snover hates it

I don't use it on zip/rar/arj/cab/mp3/avi files because they're already compressed. I also don't use it on system files or game files because I access them a lot.

I also religiously compress all the shortcuts in my Quick Menu, although I'm almost positive that it doesn't do any good (because most of them are already smaller than a disk cluster)

NTFS compression allows files to be smaller than the size of a sector.

Compressed 2 of my 3 partitions. It works quite good, even for games. Loading times seem to be slightly reduced, too.
My third partition, where I mostly store ZIPs, RARs, ACEs, MPGs, AVIs, and the such, it's left uncompressed, because the benefit would be minimal (if such). 😎

Snover wrote:

NTFS compression allows files to be smaller than the size of a sector.

Then why does my compressed Quick Launch folder have the following stats?

Size: 35.8 KB (36,687 bytes)
Size on disk: 152 KB (155,648 bytes)

Bleh, wtf, nevermind, I lied like a bitch. 😀

Smackdown. 😜

Uhh, if your using NTFS Compression shouldn't your "Size on Disk" be smaller than "Size"?

What kind of cluster size you using?

4096 bytes in each allocation unit.

Note t hat I'm not compressing the entire drive - just individual files and folders as desired.

Duh, I totally forgot that the icons to the right of the Start button were in the "Quick Launch" folder or what the "Quick Launch" folder actually was.

No wonder NTFS Compression isn't doing anything. 😀

Wonder if it would do anything with a cluster size of 512 bytes on a 752 byte file........ Might have to load up VPC/Vmware and test. Of course it would probably just compress to 512.

That's the way clusters/allocation units/whatever work: a cluster is the smallest block of space that the file system can keep track of as being assigned to a particular (or none at all). This means that if your cluster size is 512 bytes and you have a 1 byte file, a whole 512 byte cluster will be assigned to hold that file's data. If you have 100 1-byte files, 100 512-byte clusters will be assigned (for a usage of 100 * 512 = 51200 bytes - just to hold 512 bytes of data!). For 4096-byte clusters (like on my C: drive), 100 1-byte files would take up 100 * 4096 = 409600 bytes (almost a half megabyte!) of space to hold those same 512 bytes of data.

You can see from this why partitions with lost of small files will waste a lot more space (because there will be a much higher ratio of partially used clusters to full clusters), while partitions with mostly large files won't suffer nearly as badly (most of the clusters assigned to a file will be full - only the last one will probably be only partially full).

On the other hand, the smaller the cluster size, the more hard drive space is wasted keeping track of which clusters are holding what data (i.e. the MFT/FAT/whatever has to be bigger to store data for more clusters). Plus, smaller clusters mean that large files can be broken into more pieces and scattered over more area on the hard drive, potentially reducing performance as the disk head will have to jump all over the place looking for each piece.

If I cared enough to tweak my cluster size (which is most easily done by reformatting), I would make my boot partition have a small cluster size and my data partition(s) have larger cluster sizes. That way, less space would be wasted on the boot partition due to small files, while my data/games partition(s) would get less fragmented due to a fewer number of clusters required to hold the data for each file on the partition(s).

About the MFT/FAT/whatever: On NTFS, a chunk of hard drive space is allocated and named $MFT (master file table) and is used to keep track of what each cluster on the partition is being used for. On FAT (MS-DOS/Win9x), it's called the FAT (file allocation table). I don't remember what Unix/Linux calls it, but it has a similar mechanism.

EDIT: Oh yeah - to answer your question: It would only help if it could compress the file to be 512 bytes or smaller. Otherwise, it's still going to take up two 512 byte clusters.

At the end, i decompressed again all drives. Little benefit gained and HUGE hard-disks are cheap nowadays. Besides, you always notice the compression overhead.

Exactly. What extra space you're going to have gained by using NTFS compression isn't going to stop you buying more storage - it's just too small a percentage to get excited about. Also, a lot of files (especially games) using some form of compressed container storage these days.

HunterZ wrote:

About the MFT/FAT/whatever: On NTFS, a chunk of hard drive space is allocated and named $MFT (master file table) and is used to keep track of what each cluster on the partition is being used for. On FAT (MS-DOS/Win9x), it's called the FAT (file allocation table). I don't remember what Unix/Linux calls it, but it has a similar mechanism.

Just as with DOS/Windows, Unix/Linux systems can use different types of file systems. I have no idea how the more recent file systems works, and I haven't really studied Unix file systems - just enough to be able to format and partition without loosing data - but in the old days, the 'ufs' (Unix File System) began with a so-called super-block of a fixed size. The super-block contained a list of pointers (i-nodes) to fixed sized "directory files" - which again contained the file names, and i-nodes pointing the file data (or another "directory file"). It is like a pointed graph, with pointers (i-nodes) pointing to more i-nodes (and more data). Since the super-block is VITAL in order to make sense of all these pointers, it was replicated several times spread out over the disk partition.

Or something like that....