And lo on Fri, 09 Nov 2007 16:10:20 -0000, Invisible <voi### [at] devnull> did  
spake, saying:

> Phil Cook wrote:
>
>> Asking the obvious I'm assuming that the swap file isn't on the same  
>> partition?
>
> Even if it is, that would show up as a "file" and would be counted with  
> all the other files in the "40 GB" number. (Although presumably not the  
> backup size.)

Depends how you're counting. If it's sitting on its hidden lonesome in  
root and you just total the folders. Wouldn't show up on a file size  
search either unless you specifically include hidden system files.

> Also, the swap file doesn't just change size of its own accord.

Well no it changes when it needs to.

> Certainly not by 60 GB. ;-)

Why not unless you've set a maximum limit.

-- 
Phil Cook

--
I once tried to be apathetic, but I just couldn't be bothered
http://flipc.blogspot.com

Post a reply to this message

Kyle schrieb:
> Have you tried to do a search for large files?  I'd start there.
> 
nice tool to get an overview:

http://w3.win.tue.nl/nl/onderzoek/onderzoek_informatica/visualization/sequoiaview//

but it won't help, if those 60GB are no files at all, as Fabien suggests...

kk

Post a reply to this message

Le 09.11.2007 14:35, Fa3ien nous fit lire :
> Our server got a 120 Gb disk.
> 
> Data files are stored on a 100 Gb partition of it.
> That partition is NTFS, cluster size 4 Kb.
> 
> The files in that partition sums up to 40 Gb (which,
> not surprisingly, is also the size of the nightly
> backup)
> 
> Today, someone had a problem to save a file, and I've
> been horrified to see that Windows Server 2003 tells
> me there's only 2 Mb left on the partition !
> 
> I've run a defrag, which freed 250 Mb.
> 
> WHERE IS THE REST ? (there should be 60 Gb free !)
>

You need admin right to see all the files... (and more to see
more-than-hidden-resource-forks...)
Now, the defrag tools should display a nice analysis of the filled
space.
From memory, Red is fragmented, Blue is continuous and Green is
System. (grey is free space ???)
Have a look.


> What could it be ? I don't know what to do...

Ask Microsoft a 60% refund ?

> 
> Fabien.




-- 
The superior man understands what is right;
the inferior man understands what will sell.
-- Confucius

Post a reply to this message

Phil Cook wrote:
> And lo on Fri, 09 Nov 2007 16:10:20 -0000, Invisible <voi### [at] devnull> did 
> spake, saying:
> 
>> Phil Cook wrote:
>>
>>> Asking the obvious I'm assuming that the swap file isn't on the same 
>>> partition?
>>
>> Even if it is, that would show up as a "file" and would be counted 
>> with all the other files in the "40 GB" number. (Although presumably 
>> not the backup size.)
> 
> Depends how you're counting.

True.

>> Also, the swap file doesn't just change size of its own accord.
> 
> Well no it changes when it needs to.

I thought it was standard practise to set minsize = maxsize to prevent 
fragmentation...

>> Certainly not by 60 GB. ;-)
> 
> Why not unless you've set a maximum limit.

What do you mean "unless"? ;-)

Post a reply to this message

Sorry for getting back so late after the event, but
I had urgent work to do PM.

In short, a good'ol chkdsk /f solved the problem.
I didn't knew that so much empty space could be
erroneously marked as allocated... (and didn't think
if chkdsk at first because I haven't used it in years).

Thanks to everyone who tried to help :-)

Fabien.

Post a reply to this message

> Some of it could conceivably be "slack space". (A file can only be an 
> integer number of blocks long. The remaining space isn't shown in the 
> "file size", yet cannot be used for any other data because a block can 
> only belong to one file. If you look at file properties, you will see a 
> "file size" and a larger "disk on disk", which includes the slack space.)

I thought of that at first, but, no.  With 4 Kb clusters, the maximum
amount of lost space is rather small (say we got 100 000 files, which
isn't even the case, it would take 400 Mb at worst).

> Do you have that Previous Versions option switched on?

No.  That partition contains only data files, nothing system-related.

It was just clusters erroneously marked as allocated, chkdsk fixed it !

Thanks anyway.

Fabien.

Post a reply to this message

Fa3ien wrote:

> In short, a good'ol chkdsk /f solved the problem.
> I didn't knew that so much empty space could be
> erroneously marked as allocated...

Woah! o_O

That's one unhappy filesystem... heh. Glad it's all fixed now though. 
(Although you probably ought to find out *why* it did this in the first 
place...)

Post a reply to this message

>> I've run a defrag, which freed 250 Mb.
> 
> Defrags free disk space??

Theorically, it shouldn't, I'm surprised too.  The fact
is that Windows seen more free space after defrag.
chkdsk freed the rest !

Fabien.

Post a reply to this message

Fa3ien wrote:


>>> I've run a defrag, which freed 250 Mb.
>>
>> Defrags free disk space??
> 
> Theorically, it shouldn't, I'm surprised too.  The fact
> is that Windows seen more free space after defrag.
> chkdsk freed the rest !

Most likely defrag partially corrected some mis-allocated space as a 
side-effect of frobnicating the low-level FS data...

Post a reply to this message

> Fa3ien wrote:
> 
>> In short, a good'ol chkdsk /f solved the problem.
>> I didn't knew that so much empty space could be
>> erroneously marked as allocated...
> 
> Woah! o_O
> 
> That's one unhappy filesystem... heh. Glad it's all fixed now though. 
> (Although you probably ought to find out *why* it did this in the first 
> place...)

I'll check regularly to see if it happens again... Maybe it's related
to the problems I had with Raid in may. I currently run the server
without Raid1, because the bad experience showed me that no raid (with
a daily backup, anyway) is less of a potential hassle than shitty SIS
software Raid (which is more insecure because it doesn't inform you
correctly of the real array state).

Fabien.

Post a reply to this message