[Qemu-devel] Re: qemu 0.7.1 + dkms-qvm86-0.7.1 (mandriva 2005 / cooker) produces version mismatch

[Qemu-devel] Re: qemu 0.7.1 + dkms-qvm86-0.7.1 (mandriva 2005 / cooker) produces version mismatch

[Hannes Fuchs]

Hello,

Thanks for your help.

## From: Gwenole Beauchesne <gbeauchesne@mandriva.com>
## Actually also make sure you don't have a stale qvm86 module already
prior
to the dkms'ed variant from MDK. e.g. one you manually built and placed
in
a more prioritized location than the output of dkms builds.

There were no stale qvm86 or kqemu modules, I removed everthing (rpm ,
src, modules) before new tries.

##From: Pascal Terjan <pterjan@gmail.com>
## do you use the same package version of qemu and dkms-qvm86 ?

Yes, I downloaded the correct/same cooker versions.

## And anyway running cooker packages on stable version is not a good
idea. 
## Please rebuild the rpm on 2005 or use the version from
## http://fasmz.org/~pterjan/rpm/10.2/

It looks like an incompatibility of 2005 and cooker qemu/qvm86 packages.
Now I installed pterjan's qemu and kqemu module which works great!
The pjertan's qvm86 module makes errors on installing so I switched to
kqemu.

Again, thank you.
Regards,
Hannes

BTW: I installed successfully following in qemu windows xp, windows 2000
professional, windows 2000 server and centos 4 with scalix community
groupware server.

[Qemu-devel] QEMU_TMPDIR temp folder for KQEMU for Windows.

[Francois Rioux]

[-- Attachment #1: Type: text/plain, Size: 1013 bytes --]


The KQEMU doc mentions setting QEMU_TMPDIR to a ramdisk for increased performances under KQEMU which saves the memory image of the guest OS.

I'm running XP Pro as the Host with qemu version 0.7.1-3 which includes KQEMU (I can see it is enabled with 'info kqemu'.)

I've added 'set QEMU_TMPDIR=c:\tmp' to my qemu launch script.  However I can't see that file.  The folder is empty no matter how I look at it.  I know the doc says the file is hidden but shouldn't I see it if I 'dir c:/tmp /AH'? Also Properties of that folder show no files, no size.

Where is that hidden file? And how can I move it to a ram drive in Windows?

I notice that QEMU is quite slower than VMWare.  Apparently due to the way IO occur.  What are the strategies to enhance that performance?  Does anyone knows if the current patches apply to Windows builds?

 Thanks for your help.

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

[-- Attachment #2: Type: text/html, Size: 1094 bytes --]

Re: [Qemu-devel] QEMU_TMPDIR temp folder for KQEMU for Windows.

[John R. Hogerhuis]

On Mon, 2005-08-29 at 11:05 -0700, Francois Rioux wrote:

> I notice that QEMU is quite slower than VMWare.

It certainly is.

>   Apparently due to the way IO occur.  What are the strategies to
> enhance that performance?

Curious, why do you think that? There are probably a whole host of
reasons that VmWare is faster, IO devices are only one part of the
picture.

The more interesting place for optimizations is on the dynamic code
generation. VmWare is a virtualizer while QEMU employs a default
strategy of dynamically generating direct (I think) threaded code. So
the way to achieve improved speed is to improve the dynamic code
generator.

KQEMU presumably does this on X86 by inlining more of the original code
with minimal changes (i.e more tokens containing bigger swaths of native
code, and less simple instruction emulation tokens), so performance will
be more like what you could expect from a virtualizer. KQEMU is not open
source though, so if you want to fiddle with that, you probably would
have to do it on qvm86.

As to IO, one thought is to run a Windows X server (such as the free one
that comes with Cygwin) natively on the host rather than under
emulation. Do testing with tuntap networking. User-net networking is
slow, Slirp code could certainly stand some bugfixes and optimizations.

There are different tricks you can do to improve the experience. For
example, avoid booting your virtual images from scratch. Boot to
desktop, and savevm. Then in the future, boot straight off the savevm,
it is much faster that way.

-- John.

Re: [Qemu-devel] QEMU_TMPDIR temp folder for KQEMU for Windows.

[Jim C. Brown]

On Mon, Aug 29, 2005 at 11:53:26AM -0700, John R. Hogerhuis wrote:
> On Mon, 2005-08-29 at 11:05 -0700, Francois Rioux wrote:
> 
> KQEMU presumably does this on X86 by inlining more of the original code
> with minimal changes (i.e more tokens containing bigger swaths of native
> code, and less simple instruction emulation tokens), so performance will
> be more like what you could expect from a virtualizer. KQEMU is not open
> source though, so if you want to fiddle with that, you probably would
> have to do it on qvm86.
> 

Um, KQEMU/qvm86 don't do dynamic translation. They are virtualizers. They run
the code given to them (more or less) unchanged. They are simpler than VMware
because they only virtualize a subset of code (they dont support virtualizing
kernel code), so qemu still does translation for the code which cant be
virtualized (and in addition, switches become slightly more expensive due to
needing to convert register state between kernel and user code).

Without them, there is no native code run by qemu - everything is translated.

-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.

Re: [Qemu-devel] QEMU_TMPDIR temp folder for KQEMU for Windows.

[Jim C. Brown]

On Mon, Aug 29, 2005 at 11:05:05AM -0700, Francois Rioux wrote:
> 
> The KQEMU doc mentions setting QEMU_TMPDIR to a ramdisk for increased performances under KQEMU which saves the memory image of the guest OS.
> 
> I'm running XP Pro as the Host with qemu version 0.7.1-3 which includes KQEMU (I can see it is enabled with 'info kqemu'.)
> 
> I've added 'set QEMU_TMPDIR=c:\tmp' to my qemu launch script.  However I can't see that file.  The folder is empty no matter how I look at it.  I know the doc says the file is hidden but shouldn't I see it if I 'dir c:/tmp /AH'? Also Properties of that folder show no files, no size.
> 
> Where is that hidden file? And how can I move it to a ram drive in Windows?
> 

IIUC this is a reference to shmfs. So this doesn't apply to KQEMU on Windows
hosts. I'm not an expert on the Windows versions tho, so I'm not 100% sure of
this.

-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.

Re: [Qemu-devel] QEMU_TMPDIR temp folder for KQEMU for Windows.

[Francois Rioux]

[-- Attachment #1: Type: text/plain, Size: 1888 bytes --]

Thank you folks for the insights.  
 
I know everyone with the knowledge in made magic to come with the current QEMU and you're working on enhancements.  I'm unfortunately unable to help with that.  I couldn't even make my own build for on Windows! 
 
That said, I'm curioux and looking for out of the bag tricks until the next release.
 
This QEMU is fun to use and the accelerator makes it finally usable.
 
Ramdisk might have been a real performance accelerator for Windows hosts with enough RAM available.  Since I can't find the temp memory image file is saved, I can't use that option.
 
Any other hint would help.
 
Regards,
 
Francois
 

"Jim C. Brown" <jma5@umd.edu> wrote:
On Mon, Aug 29, 2005 at 11:05:05AM -0700, Francois Rioux wrote:
> 
> The KQEMU doc mentions setting QEMU_TMPDIR to a ramdisk for increased performances under KQEMU which saves the memory image of the guest OS.
> 
> I'm running XP Pro as the Host with qemu version 0.7.1-3 which includes KQEMU (I can see it is enabled with 'info kqemu'.)
> 
> I've added 'set QEMU_TMPDIR=c:\tmp' to my qemu launch script. However I can't see that file. The folder is empty no matter how I look at it. I know the doc says the file is hidden but shouldn't I see it if I 'dir c:/tmp /AH'? Also Properties of that folder show no files, no size.
> 
> Where is that hidden file? And how can I move it to a ram drive in Windows?
> 

IIUC this is a reference to shmfs. So this doesn't apply to KQEMU on Windows
hosts. I'm not an expert on the Windows versions tho, so I'm not 100% sure of
this.

-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.


_______________________________________________
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

		
---------------------------------
 Start your day with Yahoo! - make it your home page 

[-- Attachment #2: Type: text/html, Size: 2430 bytes --]

[Qemu-devel] qemu optimization

[John R. Hogerhuis]

On Mon, 2005-08-29 at 17:59 -0400, Jim C. Brown wrote:

> Um, KQEMU/qvm86 don't do dynamic translation. They are virtualizers. They run
> the code given to them (more or less) unchanged.

Sorry, I was speaking more generally (and imprecisely) about the
qemu/kqemu as a combination. As you state below, there is still dynamic
translation going on, just not by the kqemu or qvm86 modules.


(snip)

> 
> Without them, there is no native code run by qemu - everything is translated.
> 

Yep. But even in that situation, there will always be room for
improvement in how the dynamic code generator works.

I wonder, has anyone tried doing a peephole optimizer? Translate key
instruction sequences to macro instructions? There have got to be a few
such high-traffic sequences that run all the time in Windows or Linux
that could be implemented in the dynamically generated dynamic code
generator.

The most difficult part of the analysis would be to find such sequences
for interesting guest OSs and applications. I think the implementation
part would be pretty straightforward. You would have to take a hit
computing a hash the first time through a translation block so that you
could match up the block with the macroinstructions.

Actually if GCC is around on the machine, it could even be done
automatically. Put QEMU into a maintenance mode, and it would start to
collect statistics about the translation blocks. You do your normal work
on the guest machine for a little bit, maybe do a few processor
intensive things that typically take too much time.. Then tell QEMU to
stop collecting data. It looks at the translation blocks, and finds the
top ten most popular translation blocks. It generates a little C file
with the macro instructions in it, compiles it with gcc and generates a
extension to the code generator tailored to the particular guest
environment.

I guess it's an open question whether handing gcc instruction primitives
globbed together into into macroinstrucions will provide much benefit.
Depends on how smart gcc is, I guess.

-- John.

Re: [Qemu-devel] QEMU_TMPDIR temp folder for KQEMU for Windows.

[Filip Navara]

Francois Rioux wrote:
[snip]

> Ramdisk might have been a real performance accelerator for Windows 
> hosts with enough RAM available.  Since I can't find the temp memory 
> image file is saved, I can't use that option.

Why do you think that it would improve performance? Sorry, but that's 
complete rubbish... The guest RAM is allocated using standard virtual 
memory functions and as long as you have enough memory the system will 
probably leave it in the physical RAM anyway... If you don't, it's 
swapped out to page file. This is much more versatile solution since you 
don't have to reserve a chunk of the RAM for a disk and _permanently_ 
waste your memory resources this way...

>  
>
> */"Jim C. Brown" <jma5@umd.edu>/* wrote:

[snip]

>     IIUC this is a reference to shmfs. So this doesn't apply to KQEMU
>     on Windows
>     hosts. I'm not an expert on the Windows versions tho, so I'm not
>     100% sure of
>     this.
>
Correct.

- Filip

Re: [Qemu-devel] qemu optimization

[Paul Brook]

> > Without them, there is no native code run by qemu - everything is
> > translated.
>
> Yep. But even in that situation, there will always be room for
> improvement in how the dynamic code generator works.
>
> I wonder, has anyone tried doing a peephole optimizer? Translate key
> instruction sequences to macro instructions? There have got to be a few
> such high-traffic sequences that run all the time in Windows or Linux
> that could be implemented in the dynamically generated dynamic code
> generator.

You might want to look at my hand-coded backed for qemu. The intention is that 
this will eventually replace dyngen/gcc altogether. Currently everything 
except the experimental m68k target uses a mixture of the old and the 
micro-ops.

One of the differences is that most of the semantics and guest CPU state 
accesses are explicit, so it should be possible to use conventional 
optimisation techniques (including peepholes).

Source and patches can be found at
https://nowt.dyndns.org

As proof-of-concept I also implemented a simple register propagation pass, and 
got a 15% speedup on the nbench benchmark.

Paul

Re: [Qemu-devel] QEMU_TMPDIR temp folder for KQEMU for Windows.

[Francois Rioux]

[-- Attachment #1: Type: text/plain, Size: 2810 bytes --]

Filip, 
 
I'm not trying to put the guest in ram.  As you state, let's Windows manage its whole memory, paging and swapping.  I agree it would be as dumb as setting up a ramdisk to put the swapfile. Let's not trying to outsmart the OS.
 
I was trying to follow Fabrice recommendation to set the QEMU temp directory to a RAM disk while using kqemu:
 
"When using KQEMU, QEMU will create a big hidden file containing the RAM of the virtual machine. For best performance, it is important that this file is kept in RAM and not on the hard disk. QEMU uses the `/dev/shm' directory to create this file because tmpfs is usually mounted on it (check with the shell command df). Otherwise `/tmp' is used as fallback. You can use the QEMU_TMPDIR shell variable to set a new directory for the QEMU RAM file. " (excerpt from his 'kqemu-doc.html' file).

I (maybe incorrectly) interpreted that as setting the temp dir in RAM.  But I'm not that familiar with Linux and I don't know what /shm or tmpfs are.  I guessed they were 'virtual' storage devices in RAM.  I'm simply trying to mimic that under Windows.  Had I been right, using a RAM disk to store the 'big hidden file containing the RAM of the virtual machine' would not be useless given enough ram is available, would it?  But I can't find that file at all under Windows and my understanding of the whole situation is probably wrong, or at least part of it.
 
Reading your other posts in this forum I understand you have an deep knowledge of Linux, Windows and QEMU insights so I take from your answer that RAMDISK is not gonna help kqemu.
 
Regards,
 
Francois

Filip Navara <navaraf@reactos.com> wrote:
Francois Rioux wrote:
[snip]

> Ramdisk might have been a real performance accelerator for Windows 
> hosts with enough RAM available. Since I can't find the temp memory 
> image file is saved, I can't use that option.

Why do you think that it would improve performance? Sorry, but that's 
complete rubbish... The guest RAM is allocated using standard virtual 
memory functions and as long as you have enough memory the system will 
probably leave it in the physical RAM anyway... If you don't, it's 
swapped out to page file. This is much more versatile solution since you 
don't have to reserve a chunk of the RAM for a disk and _permanently_ 
waste your memory resources this way...

> 
>
> */"Jim C. Brown" /* wrote:

[snip]

> IIUC this is a reference to shmfs. So this doesn't apply to KQEMU
> on Windows
> hosts. I'm not an expert on the Windows versions tho, so I'm not
> 100% sure of
> this.
>
Correct.

- Filip


_______________________________________________
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

		
---------------------------------
 Start your day with Yahoo! - make it your home page 

[-- Attachment #2: Type: text/html, Size: 3477 bytes --]

Re: [Qemu-devel] QEMU_TMPDIR temp folder for KQEMU for Windows.

[Paul Brook]

> "When using KQEMU, QEMU will create a big hidden file containing the RAM of
> the virtual machine. For best performance, it is important that this file
> is kept in RAM and not on the hard disk. QEMU uses the `/dev/shm' directory
> to create this file because tmpfs is usually mounted on it (check with the
> shell command df). Otherwise `/tmp' is used as fallback. You can use the
> QEMU_TMPDIR shell variable to set a new directory for the QEMU RAM file. "
> (excerpt from his 'kqemu-doc.html' file).

Your mistake was assuming that this paragraph applies to the windows version 
of kqemu. It seems that it only applies to the linux (and maybe bsd) version.

Paul

Re: [Qemu-devel] qemu optimization

[John R. Hogerhuis]

On Tue, 2005-08-30 at 12:17 +0100, Paul Brook wrote:

> You might want to look at my hand-coded backed for qemu. The intention is that 
> this will eventually replace dyngen/gcc altogether. Currently everything 
> except the experimental m68k target uses a mixture of the old and the 
> micro-ops.
> 

Handwritten code generators are definitely the future for QEMU, at least
where virtualization doesn't make sense (host and guest CPU don't match,
or when you don't have root or admin access to the host).

> One of the differences is that most of the semantics and guest CPU state 
> accesses are explicit, so it should be possible to use conventional 
> optimisation techniques (including peepholes).
> 
> Source and patches can be found at
> https://nowt.dyndns.org
> 
> As proof-of-concept I also implemented a simple register propagation pass, and 
> got a 15% speedup on the nbench benchmark.
> 
> Paul
> 
> 

I just downloaded the patched tree off your page. Tried to build it
(./configure && make) compiling on Debian GNU/Linux, gcc version 3.3 but
no-workey.
Any idea what I'm doing wrong (I haven't given it a hard look yet)?

(last line of build, let me know if you need more).

gcc -Wall -O2 -g -fno-strict-aliasing -fomit-frame-pointer -I.
-I/home/john/projects/qemu/target-mips -I/home/john/projects/qemu
-I/home/john/projects/qemu/host-i386 -D_GNU_SOURCE
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE
-I/home/john/projects/qemu/fpu -I/home/john/projects/qemu/slirp -c -o
translate-all.o /home/john/projects/qemu/translate-all.c
/home/john/projects/qemu/translate-all.c: In function
`cpu_restore_state':
/home/john/projects/qemu/translate-all.c:1496: error: `CC_OP_DYNAMIC'
undeclared (first use in this function)
/home/john/projects/qemu/translate-all.c:1496: error: (Each undeclared
identifier is reported only once
/home/john/projects/qemu/translate-all.c:1496: error: for each function
it appears in.)
/home/john/projects/qemu/translate-all.c:1497: error: structure has no
member named `cc_op'
make[1]: *** [translate-all.o] Error 1
make[1]: Leaving directory `/home/john/projects/qemu/mips-softmmu'
make: *** [all] Error 1
~/projects/qemu :( 

Re: [Qemu-devel] qemu optimization

[Paul Brook]

> I just downloaded the patched tree off your page. Tried to build it
> (./configure && make) compiling on Debian GNU/Linux, gcc version 3.3 but
> no-workey.
> Any idea what I'm doing wrong (I haven't given it a hard look yet)?

Fixed.

Paul

Re: [Qemu-devel] QEMU_TMPDIR temp folder for KQEMU for Windows.

[ace]

Hi.

Two points for you:
1. currently your tempfile with qemu quest system memory is located on
disk. Is your disk working hard? If you have enough free ram that you
consider the ramdisk, the whole file is probably cached in host system
memory so that read/write access is fast. Of course there it will be
flushed to disk, but probably asynchronously and not every time anything
in the file changes (depends on windows filesystem settings). So it
probably doesn't slow qemu down too much. I think if you have the ram,
the ramdisk surelly will help, but I don't know by how much. I can test
that.

2. you say you can't see the temporary file. Neither do I, on linux. I
suspect it is not hidden using plain filesystem attributes. On linux, if
you open a file and then delete (unlink) it, you can still work with it
until you hold the file descriptor. Only when you close the file, it is
removed from disk. But as soon as you unlink it, all referrences to it
are removed from the filesystem hierarchy. Therefore, no other program
(e.g. dir, ls) except the filesystem kernel driver knows about it. You
see no file, but something is still using up disk space (if you use
programs to show free disk space). Maybe Windows supports this too.

Peter

Francois Rioux wrote:

> Filip,
>  
> I'm not trying to put the guest in ram.  As you state, let's Windows
> manage its whole memory, paging and swapping.  I agree it would be as
> dumb as setting up a ramdisk to put the swapfile. Let's not trying to
> outsmart the OS.
>  
> I was trying to follow Fabrice recommendation to set the QEMU temp
> directory to a RAM disk while using kqemu:
>  
> "When using KQEMU, QEMU will create a big hidden file containing the RAM
> of the virtual machine. For best performance, it is important that this
> file is kept in RAM and not on the hard disk. QEMU uses the `/dev/shm'
> directory to create this file because |tmpfs| is usually mounted on it
> (check with the shell command |df|). Otherwise `/tmp' is used as
> fallback. You can use the QEMU_TMPDIR shell variable to set a new
> directory for the QEMU RAM file. " (excerpt from his 'kqemu-doc.html' file).
> 
> I (maybe incorrectly) interpreted that as setting the temp dir in RAM. 
> But I'm not that familiar with Linux and I don't know what /shm or tmpfs
> are.  I guessed they were 'virtual' storage devices in RAM.  I'm simply
> trying to mimic that under Windows.  Had I been right, using a RAM disk
> to store the 'big hidden file containing the RAM of the virtual machine'
> would not be useless given enough ram is available, would it?  But I
> can't find that file at all under Windows and my understanding of the
> whole situation is probably wrong, or at least part of it.
>  
> Reading your other posts in this forum I understand you have an deep
> knowledge of Linux, Windows and QEMU insights so I take from your answer
> that RAMDISK is not gonna help kqemu.
>  
> Regards,
>  
> Francois
> 
> */Filip Navara <navaraf@reactos.com>/* wrote:
> 
>     Francois Rioux wrote:
>     [snip]
> 
>     > Ramdisk might have been a real performance accelerator for Windows
>     > hosts with enough RAM available. Since I can't find the temp memory
>     > image file is saved, I can't use that option.
> 
>     Why do you think that it would improve performance? Sorry, but that's
>     complete rubbish... The guest RAM is allocated using standard virtual
>     memory functions and as long as you have enough memory the system will
>     probably leave it in the physical RAM anyway... If you don't, it's
>     swapped out to page file. This is much more versatile solution since
>     you
>     don't have to reserve a chunk of the RAM for a disk and _permanently_
>     waste your memory resources this way...
> 
>     >
>     >
>     > */"Jim C. Brown" /* wrote:
> 
>     [snip]
> 
>     > IIUC this is a reference to shmfs. So this doesn't apply to KQEMU
>     > on Windows
>     > hosts. I'm not an expert on the Windows versions tho, so I'm not
>     > 100% sure of
>     > this.
>     >
>     Correct.
> 
>     - Filip
> 
> 
>     _______________________________________________
>     Qemu-devel mailing list
>     Qemu-devel@nongnu.org
>     http://lists.nongnu.org/mailman/listinfo/qemu-devel
> 
> ------------------------------------------------------------------------
> Start your day with Yahoo! - make it your home page
> <http://us.rd.yahoo.com/evt=34442/*http://www.yahoo.com/r/hs>
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] QEMU_TMPDIR temp folder for KQEMU for Windows.

[Filip Navara]

Francois Rioux wrote:

> Filip,
>  
> I'm not trying to put the guest in ram.  As you state, let's Windows 
> manage its whole memory, paging and swapping.  I agree it would be as 
> dumb as setting up a ramdisk to put the swapfile. Let's not trying to 
> outsmart the OS.

There's slight misunderstaning there. What I'm saying is that on 
QEMU/Windows there's no "big hidden file containing the RAM of the 
virtual machine", it's simply stored in the host RAM (and the host OS 
can decide to page out parts of it to disk - to pagefile.sys, or 
whatever is setup - but it may not do so if you have enough physical 
memory available).

On other platforms where QEMU runs there's the famous "big hidden file 
containing the RAM of the virtual machine" and it's mapped into memory 
and used as the storage of guest RAM. Whenever the OS decides the 
in-memory contents are synced with the on-disk file. Actually I don't 
understand the benefits of putting it on real ramdisk (...but /dev/shm, 
or actually TMPFS is not *REAL RAMDISK* since it grows and shrink based 
on the contents and the pages can be be swapped out ... so in a way it 
does the same thing as we accomplish on Windows with pure virtual memory 
allocation).

Maybe I haven't explained the details correctly (and I'm not exactly 
sure about them on the *nix side of things), but the point is that no 
such file containing the guest RAM is present on Windows.

- Filip

Re: [Qemu-devel] QEMU_TMPDIR temp folder for KQEMU for Windows.

[Doctor Bill]

On 9/3/05, ace <acelists@atlas.sk> wrote:
> Hi.
> 2. you say you can't see the temporary file. Neither do I, on linux. I
> suspect it is not hidden using plain filesystem attributes. On linux, if
> you open a file and then delete (unlink) it, you can still work with it
> until you hold the file descriptor. Only when you close the file, it is
> removed from disk. But as soon as you unlink it, all referrences to it
> are removed from the filesystem hierarchy. Therefore, no other program
> (e.g. dir, ls) except the filesystem kernel driver knows about it. You
> see no file, but something is still using up disk space (if you use
> programs to show free disk space). Maybe Windows supports this too.

98% correct.  In linux you can still access open unlinked files from
other processes if you know the process id and fileno.  A link is
maintained in the proc filesystem.  Some consider this a security
hole, others consider it a very useful feature.

Bill