M
Mike Hall - MVP
Ken Blake said:
Ken
Compressing files is not so bad.. compressing drives is very bad..
Ken
Compressing files is not so bad.. compressing drives is very bad..
D
David H. Lipman
From: "Mike Hall - MVP" <mikehall@remove_mvps.com>
| Ken
| Compressing files is not so bad.. compressing drives is very bad..
| --
| Mike Hall - MVP
| Mike's Window - My Blog..
| http://msmvps.com/blogs/mikehall/default.aspx
Yes. My understanding is do NOT compress the OS or applications, just data.
| Ken
| Compressing files is not so bad.. compressing drives is very bad..
| --
| Mike Hall - MVP
| Mike's Window - My Blog..
| http://msmvps.com/blogs/mikehall/default.aspx
Yes. My understanding is do NOT compress the OS or applications, just data.
J
John John (MVP)
Mike said:
It depends on how big the files are and on what you do with them. A
large file is not wholly or completely "decompressed" when it is
accessed, the same thing as when you read a file, not all of it is
loaded into memory it's loaded in "chunks" slightly bigger than the
requested part of the file, the file is read a few KBs ahead of the
request and loaded a bit at a time. You may not see significant
differences when you open a single file but applications that process or
handle a large number of files may be negatively impacted by file
compression.
Compression can also cause a significant bottleneck if the files are
served over a network, files cannot be transported over a network in a
compressed state, they have to be fully decompressed before they can be
sent over the network and this can cause a significant performance
deterioration. As a general rule user files on file servers should not
be compressed, the same applies to machines serving files on small
workgroups and home network.
John
T
Twayne
ME said:
Tim's comments make sense. I've compressed my
external drives just to maximize the amount of
available space and another drive I store
development programs on.
I haven't and wouldn't compress my boot drive
because XP is slow enough as it is, but I know a
few people who do. Personally I wouldn't advise
compressing drives, or even just files, unless
there is some benefit to be gained. Things like
jpegs and gifs can't compress much more than they
already are and in fact sometimes grow a bit when
you compress them, but text in most any files of
any kind, and bitmap (.bmp, etc) files and many
non-executables can be compressed by fantastic
ratios. Compress a .bmp and watch how small it
gets<g>.
As a general rule, compressed files won't cause
noticeable slowdowns and I've never noticed any
but I have a fairly fast machine with 7200 rpm
drives so that helps a little too. If something
should run noticeably slow on you, just uncompress
it.
Note that windows also compresses "old" files,
files that don't get used often, unless you tell
it not to, when you do a disk cleanup.
So in the end, I'd say compress away if you wish,
but except the boot disk (system drive) from
compression, since it gets so much constant use.
I suppose again ymmv though; just my opinion.
HTH,
Twayne
T
Twayne
Personally, I don't compress anything, and don't
recommend doing so,
unless you are very short of disk space.
Compressing may slow down
access to the files.[/QUOTE]
Then again you should see what compression can do
for drive images; it can seriously extend the size
of a 500 Gig drive for data backups. Not so much
of course with executables, etc., but data is
often squeezable like all get out.
I haven't noticed any of the possible
slowdowns because of it, and I do admit that like
anything else it's one more set of
places/opportunities for something to go wrong.
There is a lot to be said for the "most direct"
means to an end when you talk reliability.
Twayne
T
Twayne
"Ken Blake, MVP"
How so? I can't envision anything "very bad"
about it, or "bad" at all, really.
Twayne
How so? I can't envision anything "very bad"
about it, or "bad" at all, really.
Twayne
T
Twayne
From: "Mike Hall - MVP"
Agreed; OS and applications won't compress enough
to make much difference to anything anyway. XP's
compression barely touches them.
Agreed; OS and applications won't compress enough
to make much difference to anything anyway. XP's
compression barely touches them.
T
Twayne
Mike said:
Just for grins, I just compressed a very large
database file. There is a very definite
performance hit there! I was surprised too, to
see the pagefile grow as large as it did; normally
it stays around a few hundred meg but it grew to
well over 700 Meg. Not sure I understand why, but
it explains the performance hit, or part of it at
least.
That's not really the case. Compressed files are
just nibbles, bits & bytes like any other file to
the network. Compressed files are ONLY compressed
while they reside on the disk. They are
decompressed as they are read and enter the
transfer buffers already decompressed in XP, so
when they cross the network, they ARE
decompressed; it's not that they are required to
be. It's just how XP works.
If the source and destination are both
compressed folders, then it's decompressed, sent
across the network, and recompressed as it is
written to the disk. THAT can be quite a
performance hit too.
But compressed at the source and uncompressed at
the destination would simply mean it didn't go
thru the compression process before being written
to the destination drive, so less of a bottleneck.
I've never paid attention, but I doubt the
compression from the source to uncompressed at the
destination would be very noticeable unless you
were running a very high speed network faster than
say a typical 10/100 setup.
Then: A file compressed by say WinZip or 7Zip
or whatever, will readily transfer over a
network, meaing compression has nothing to do with
anything. The fact that a file is compressed or
not makes no difference to the transfer protocols;
it's only data to them & nothing cares whether
it's a jar, tar, zip or any of the other several
formats that are possible.
Cheers,
Twayne
K
Ken Blake, MVP
Yes, I said "may." It adds the extra time required to compress and
uncompress the files when accessing them, but because the compressed
files are smaller, the I/O to those files is faster. Which is more
important depends on the relative speeds of the processor and the disk
drive, so it isn't always the same for everyone (nor is the difference
significant for everyone).
K
Ken Blake, MVP
Yes, I generally agree with those statements.
J
John John (MVP)
Twayne said:
We are talking about NTFS compression and that is how it is, they are
required to be decompressed because NT operating systems cannot copy,
move or send NTFS compressed files without decompressing them, it cannot
copy, move or send then to another folder on the same volume, to another
volume or across a network in a compressed state.
John
T
Twayne
Twayne said:
I can't imagine where you're getting that from;
data is data and that's it. Long ago there were
problems with eof markers, etc., but those are no
longer problems these days and definitely not on
XP.
Somehow I suspect you are referring to some
nuance that no longer exists and is a non-issue as
the reasons why the files are compressed only on
the hardware and decompressed as it leaves it. I
can use WinZip to create the exact same legacy zip
that XP creates, amongst many others, and they
will copy just fine, even with the TLD modified to
try to fool the system into thinking it compressed
the file. Admittedly a poor/simple bit of foolery,
but still indicative.
Unless you can make yourself a lot clearer on
this, I think there is nothing more I have to say
to you; you're simply reiterating and not adding
to the information in any way to support what
you're saying, so ... nothing left to discuss.
Twayne
D
David H. Lipman
From: "Twayne" <[email protected]>
| I can't imagine where you're getting that from;
| data is data and that's it. Long ago there were
| problems with eof markers, etc., but those are no
| longer problems these days and definitely not on
| XP.
| Somehow I suspect you are referring to some
| nuance that no longer exists and is a non-issue as
| the reasons why the files are compressed only on
| the hardware and decompressed as it leaves it. I
| can use WinZip to create the exact same legacy zip
| that XP creates, amongst many others, and they
| will copy just fine, even with the TLD modified to
| try to fool the system into thinking it compressed
| the file. Admittedly a poor/simple bit of foolery,
| but still indicative.
| Unless you can make yourself a lot clearer on
| this, I think there is nothing more I have to say
| to you; you're simply reiterating and not adding
| to the information in any way to support what
| you're saying, so ... nothing left to discuss.
| Twayne
Think for a minute...
LZH, ZIP, ARC, etc, are algorithmic protocols independent of partition schemes.
Compression on NT requires NTFS and is OS dependent. It is different and JJ is correct.
BTW: *All* of our (my "company") data on our AD based server is using compression and
frankly, I don't see any degradation in reading/writing data over the wire. It certainly
has stretched that .25TB volume for us.
| I can't imagine where you're getting that from;
| data is data and that's it. Long ago there were
| problems with eof markers, etc., but those are no
| longer problems these days and definitely not on
| XP.
| Somehow I suspect you are referring to some
| nuance that no longer exists and is a non-issue as
| the reasons why the files are compressed only on
| the hardware and decompressed as it leaves it. I
| can use WinZip to create the exact same legacy zip
| that XP creates, amongst many others, and they
| will copy just fine, even with the TLD modified to
| try to fool the system into thinking it compressed
| the file. Admittedly a poor/simple bit of foolery,
| but still indicative.
| Unless you can make yourself a lot clearer on
| this, I think there is nothing more I have to say
| to you; you're simply reiterating and not adding
| to the information in any way to support what
| you're saying, so ... nothing left to discuss.
| Twayne
Think for a minute...
LZH, ZIP, ARC, etc, are algorithmic protocols independent of partition schemes.
Compression on NT requires NTFS and is OS dependent. It is different and JJ is correct.
BTW: *All* of our (my "company") data on our AD based server is using compression and
frankly, I don't see any degradation in reading/writing data over the wire. It certainly
has stretched that .25TB volume for us.
J
John John (MVP)
Twayne said:
I'm getting that from information that is readily available to anyone
who cares to go to the Microsoft site and look it up!
No, I'm not talking about any of that, I am talking about NTFS
compression, nothing more and nothing else, you are the one who is
trying to muddle the subject by bringing in those completely irrelevant
subjects and third party utilities into the conversation.
How much clearer can it be? "NT operating systems cannot copy, move or
send NTFS compressed files without decompressing them, it cannot copy,
move or send then to another folder on the same volume, to another
volume or across a network in a compressed state." What is it that is
too complicated for you to understand in that simple sentence?
Instead of wasting everybody's time with your useless posts maybe you
should spend a bit of *your* time searching and reading up on the
subject, you can start here: http://support.microsoft.com/kb/251186
John
B
Bill in Co.
John said:
I think he needs to go back and finish up that AA degree - or certificate.
U
Unknown
You and Bill inCo. keep this up and you'll get Twayne started on registry
cleaners again.
cleaners again.
P
Pegasus \(MVP\)
Twayne said:
Perhaps this little experiment will let you see things from a different
angle.
1. Get yourself a small flash disk, e.g. 1 GByte.
2. Format it with this command:
format g: /fs:ntfs /v:"BigFlashDisk" /c
(the /c switch enables compression)
3. Using notepad.exe, create the file c:\20.txt, consisting of many lines of
only lower case letters "a". This will be a highly compressible
file. Use copy & paste to make the file 20,000 bytes in size.
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
4. Create this batch file:
@echo off
cd 2> g:\0.txt
dir g:\
echo Make a note of the free bytes number!
pause
for /L %%a in (1,1,100) do copy c:\20.txt g:\1%%a.txt > nul
dir g:\
ping localhost -n 5 > nul
dir g:\ | find /i "free"
Your flash drive now contains 100 files of 20 kBytes. The files should
consume 2 MBytes. They are ordinary text files that any program such
as notepad, wordpad or word can read - even the "type" command can
display them. None of these commands knows anything about file
compression.
Questions:
- When comparing the "free" bytes before and after, what is the
difference? 2 MBytes?
- When running the command "dir g:\", what is the size shown for
each file? For the sum of all files?
- When comparing the two "free" numbers shown as the batch file ends,
why is the first number less than the second number that is displayed
five seconds later?
I would be interested in your answers and explanations. To conclude the
exercise, you should repeat the above tests with a partition that has
compression disabled, then answer the same questions.
M
Mike Hall - MVP
Unknown said:
LOL.. I think Pegasus may just have tipped the balance..
U
Unknown
I think Twayne will be 'too busy' to do all what Pegasus suggests and
therefore the debate will continue
as it has for registry cleaners.
therefore the debate will continue
as it has for registry cleaners.
I
Ian D
JS said:
MS has recently released the exFAT file system which is a replacement
for FAT32, and allows XP to format partitions greater than 32GB. Its
prime purpose is for external drives that are shared with systems that
don't use NTFS.
http://support.microsoft.com/kb/955704/