This is the mail archive of the cygwin@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Using Cygwin on NT 4.0 and Win2000; a user experience


>>>>> "Max" == Max Bowsher <maxb@ukf.net> writes:

Max> Martin Buchholz wrote:
>> - The recent change to make NTFS files SPARSE by default is a
>> disaster -- less space and time efficient for "normal" files.
>> Please undo this.  More details in a separate message.

Max> Actual test data relating to this would be very interesting to see.

Some was included in my other post.  I would have done a more
conclusive test, but I now have a working machine that is doing
productive work, and I hesitate to go through another two cycles of
painful cygwin1.dll installs.  But I would be willing to do this if
that's what it would take to convince you folks to undo the sparse
file patch.

If you have a Windows 2000 machine (no service packs) and a recent
cygwin, try this experiment:

$ ls -l /etc/passwd
-rw-rw-rw-    1 Martin B Users         628 May 13 04:10 /etc/passwd
$ perl -e 'system("df ."); for (1 ... 1024) { system("cp /etc/passwd foobar$_"); } system("df .")'
Filesystem           1k-blocks      Used Available Use% Mounted on
d:                    11767580   4290332   7477248  37% /d
Filesystem           1k-blocks      Used Available Use% Mounted on
d:                    11767580   4290332   7477248  37% /d

That's 4kb per small (but not tiny) file with my patch applied.
How much space does yours take?  It would be interesting to see
results on Windows XP as well.

(again:) For best reproducibility, I suggest
- windows 2000, no service packs
- do the experiment on an ntfs partition formatted by windows 2000.

I have not done this exact experiment on an unpatched Cygwin, but I
predict it would take either 32kb or 64kb per file (also dependent on
the filesystem cluster size, but that should default to 4kb).

>> - The "grep" package comes with a grep.exe (and no file "grep"), but
>> no egrep.exe (instead it has a "egrep").  Of course this is easy for
>> the user to fix, but the package should be fixed as well.

Max> There is nothing wrong here - it doesn't need to be fixed.

There is non-zero support in Sun's Java SDK to allow building using
Cygwin tools (although MKS is the "official" supported platform).
In one of the Makefiles is this line:

EGREP          = $(UNIXCOMMAND_PATH)egrep.exe

Arguably, this is bad code.  You should run a command via its name,
sans any .EXE extension.  But Cygwin should be consistent; either all
executables are named FOO, or they're named FOO.EXE.  Make up your mind.

>> - There have been many reports of rsync hanging, accompanied by an
>> "rsync" process that cannot be killed by "kill -9".  I have
>> experienced the same, but only on NT 4.0 SP6, not on Win2000.

Max> Actually not that many reports, and no solid info on how to reproduce the
Max> hang.
Max> Since no one can find out exactly why it is hanging, it can't be fixed.

It's a stress test.  rsync'ing 5 files almost always works; rsync'ing
50000 files almost always fails.

I can reproduce it consistently on NT 4.0 SP6, but I don't have the
time to become a Cygwin, rsync, and winsock expert so that I can debug it.

Martin

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]