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