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

On Fri, 09 Nov 2007 11:46:23 -0300, Nicolas Alvarez wrote:

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

I was wondering that myself - disk cleanup would, but not a defrag...

Jim

Post a reply to this message

On Fri, 09 Nov 2007 16:02:22 +0100, M_a_r_c wrote:

> "Nicolas Alvarez" <nic### [at] gmailisthebestcom> a écrit dans
> le message de news: 473472c5$1@news.povray.org...
>> Fa3ien escribió:
>>> I've run a defrag, which freed 250 Mb.
>>
>> Defrags free disk space??
> 
> I am not an expert but maybe if it optimizes disk occupation by filling
> blocks instead of letting empty portions of blocks.

Nope, a block in most* filesystems can only belong to a single file, not 
to multiple files, and anything left over in the tail end is lost.

Jim

* I say "most* because I know of at least one filesystem where that isn't 
true - NetWare TFS on NetWare 4.x included a feature called "block 
suballocation", where the block size for any volume was set to 64KB.  
When a file was written out to disk - say, a 65KB file, you would 
initially use two full 64KB blocks, and the last KB would leave 63KB of 
space wasted.  Not long after the write was completed, though, a process 
would move that into a special "suballocated" block - AIUI, the 
suballocation blocks were of each size possible for the system to handle 
- 32, 16, 8, 4, 2, 1 (KB all) and 512 bytes.  The file could then be 
stored on disc in such a way that the maximum space lost was 511 bytes 
for any given file.

The reason this was done was because in early NetWare servers, the admin 
had to guess whether there would be lots of little files or not so many 
large files in order to pick the proper block size to balance performance 
and storage utilisation.  BSA removed the need to do that; it was a 
feature added at a time when disk storage was fairly expensive, so that + 
background compression could save you a ton of money on storage.

Obviously, in a time when a 1 TB external storage device costs ~$350, 
that's not so important now.

Jim

Post a reply to this message