Warp wrote:
>   Question: Assuming fully defragmented data, which is faster to read data
> from a few big files: FAT32 or NTFS?

If you're reading the entire file, I would guess it's roughly equal. If 
you're seeking around a lot, I'd guess it's NTFS.

Why?  FAT uses a linked list of clusters, with the first cluster pointed to 
be the directory entry, as the allocated clusters of the file. (That's the 
File Allocation Table: the linked lists.)

NTFS just stores the first cluster and number of clusters in the file table, 
so calculating what cluster a given block of the file is on is probably 
easier and requires fewer trips back to the start of the disk. I.e., you 
don't have to read the disk to seek in the file.

You can even hear this if you have a floppy drive. Copy a 1 meg file to a 
floppy, and you can hear the seek back to the FAT every handful of tracks 
written.

This is just a guess, mind. I wouldn't think there's a whole lot of 
difference on a machine with enough memory to hold the whole FAT in kernel 
buffers.

-- 
   Darren New, San Diego CA, USA (PST)
   There's no CD like OCD, there's no CD I knoooow!

Post a reply to this message

Invisible wrote:
> Warp wrote:
> 
>>   I can't understand why defragmentation takes such humongous amounts of
>> time. There were something like 40 or 50 GB worth of fragmented data,
>> but if you calculate how many times you can copy 50 GB inside a modern
>> SATA disk, I think that in 35 hours you could copy it over and over
>> thousands of times. (Assuming it would take 1 minute to copy 50 GB of
>> data, you could copy it over 2000 times in 35 hours.)
>>
>>   Why does it take such a humongous amount of time? I can't understand.
> 
> Defragging is limited primarily by how fast you can thrash the heads 
> back and forth, not by the maximum sequential transfer speed for the drive.
> 
> I bet solid-state drives would defrag a lot faster. (But then, why would 
> you bother defragging a solid-state drive in the first place?)

SSD also has limited "write" times, so, defragging the thing would end 
up re-writing the data, and thus hastening the death of the media. Its 
why most OSes that use them are "tweaked" so they never, if possible, 
write the same file back to the same sectors each time, they way you 
would on a HDD.

-- 
void main () {

     if version = "Vista" {
       call slow_by_half();
       call DRM_everything();
     }
     call functional_code();
   }
   else
     call crash_windows();
}

<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models, 
3D Content, and 3D Software at DAZ3D!</A>

Post a reply to this message

I don't understand the problems I'm getting defragmenting.

  I'm trying to defragment my primary Windows partition, which is NTFS.
It's failing to defragment one big file because there's "no space" for it.
The file is about 1 GB in size, and there's over 9 GB of free space in the
partition.

  The problem is that while defrag is defragmenting all the other files,
for some reason it's only compacting *some* of the files to be at the
beginning of the partition, but not others. The free space is scattered
with tiny small files which the defragmenter is not compacting, even though
it compacted other files just fine. The majority of the contents were nicely
packed to the beginning of the partition, except for these hundreds of tiny
files. And no, the tiny files are *not* marked as "unmovable". They are
marked with the same color as all the other movable files.

  The other, lighter defragger is behaving the exact same way: It's just
refusing to move these small files, and consequently failing to defrag the
one huge file. No reason is given in either the visual representation of the
drive (all these tiny files are colored as regular, movable data) nor the
analysis reports for this.

  As a consequence, I simply *can't* add any file bigger than a certain size
to this partition without it becoming fragmented. There isn't enough
contiguous free space because of all these scattered tiny files.

  I can't understand why both programs are doing this.

-- 
                                                          - Warp

Post a reply to this message

>  I'm trying to defragment my primary Windows partition, which is NTFS.
> It's failing to defragment one big file because there's "no space" for it.
> The file is about 1 GB in size, and there's over 9 GB of free space in the
> partition.

Buy a new hard drive with more free space?  Seriously, lots of people fail 
to factor in how much their time is worth when trying to fix stuff.

Post a reply to this message

scott <sco### [at] scottcom> wrote:
> >  I'm trying to defragment my primary Windows partition, which is NTFS.
> > It's failing to defragment one big file because there's "no space" for it.
> > The file is about 1 GB in size, and there's over 9 GB of free space in the
> > partition.

> Buy a new hard drive with more free space?  Seriously, lots of people fail 
> to factor in how much their time is worth when trying to fix stuff.

  So because Windows is unable to defragment a big file I should buy a
new hard drive? Exactly how is that going to help? It's not like a hard
drive is going to defragment the file.

-- 
                                                          - Warp

Post a reply to this message

>  So because Windows is unable to defragment a big file I should buy a
> new hard drive?

If you really want the file defragmented, then yes, this might be the 
cheapest way if you consider how much your time is worth.

> Exactly how is that going to help?

Well just the act of copying it over to another hard drive will probably 
defragment it, and having more than 9GB of free space on a new hard drive 
will likely make your life easier in terms of fragmented files in future.

Post a reply to this message

scott <sco### [at] scottcom> wrote:
> > Exactly how is that going to help?

> Well just the act of copying it over to another hard drive will probably 
> defragment it

  Copying what over? The entire Windows installation?

  I'm not exactly sure XP survives such a transfer while still being fully
bootable from the new drive. Does it?

  (I know from experience that a linux system can be fully transferred from
one disk to another with a simple "cp -ax", and it will then work identically
when the disks are swapped. However, I have got the impression that with
Windows it's not that easy.)

  Anyways, it's just one fragmented file. It's not such a big deal. I'm just
wondering *why* the small files are not being compacted to the beginning of
the partition in order to create a larger contiguous empty space.

-- 
                                                          - Warp

Post a reply to this message

>  Copying what over?

Just the 1GB file that is fragmented so badly.  If the destination drive has 
enough non-fragmented free space the file should be defragmented as it is 
copied.  If your original drive has enough non-fragmented free space you can 
then just copy it back and it should be in a much better state.  Note that 
if this file is a windows system file you might need to do this outside of 
windows for obvious reasons.

>  I'm not exactly sure XP survives such a transfer while still being fully
> bootable from the new drive. Does it?

I don't see any big reasons why it wouldn't survive, you might have to 
fiddle with a couple of things before it booted though (like MBR and the 
boot.ini file).  There are also lots of 3rd party programs that will do this 
automatically for you, I'd be surprised if there wasn't a freeware one.

Post a reply to this message

Warp wrote:
>   I don't understand the problems I'm getting defragmenting.
> 
>   I'm trying to defragment my primary Windows partition, which is NTFS.
> It's failing to defragment one big file because there's "no space" for it.
> The file is about 1 GB in size, and there's over 9 GB of free space in the
> partition.
> 
>   The problem is that while defrag is defragmenting all the other files,
> for some reason it's only compacting *some* of the files to be at the
> beginning of the partition, but not others. The free space is scattered
> with tiny small files which the defragmenter is not compacting, even though
> it compacted other files just fine. The majority of the contents were nicely
> packed to the beginning of the partition, except for these hundreds of tiny
> files. And no, the tiny files are *not* marked as "unmovable". They are
> marked with the same color as all the other movable files.

That's pretty random - and dissapointing.

A few things to consider:

1. I wonder if this is related to the MFT reservation area?

2. You might try using the "contig" tool free from System Internals. It 
can be set to run during the boot sequence, so it has more or less 
exclusive access to the disk.

3. Having a 1GB file split into (say) 3 fragments probably won't have 
any measurable performance impact. It's when you have millions of 4KB 
fragments that you have a problem.

Post a reply to this message

scott <sco### [at] scottcom> wrote:
> >  Copying what over?

> Just the 1GB file that is fragmented so badly.  If the destination drive has 
> enough non-fragmented free space the file should be defragmented as it is 
> copied.  If your original drive has enough non-fragmented free space you can 
> then just copy it back and it should be in a much better state.  Note that 
> if this file is a windows system file you might need to do this outside of 
> windows for obvious reasons.

  But that's the problem: There *isn't* enough contiguous space for the
large file to be stored unfragmented because there's a bunch of small files
scattered all over the free space, and the defragmenter is refusing to move
those files to make space, for an unknown reason.

-- 
                                                          - Warp

Post a reply to this message