Re: Fat32 vs NTFS ?
From: DevilsPGD (ihatespam_at_crazyhat.net)
Date: 02/27/05
- Next message: DevilsPGD: "Re: Dual Monitor - Stretch Taskbar Onto Both Windows"
- Previous message: Keith: "Permission Problem"
- In reply to: Ad: "Re: Fat32 vs NTFS ?"
- Next in thread: André Gulliksen: "Re: Fat32 vs NTFS ?"
- Messages sorted by: [ date ] [ thread ]
Date: Sun, 27 Feb 2005 11:11:54 -0700
In message <1123clhb8n1scb2@corp.supernews.com> Ad
<graphi47uk@y.a.h.o.o.co.uk> wrote:
>DevilsPGD wrote:
>> Thanks to journaling and the way the file system is distributed, chances
>> of the complete disk being lost because any one
>> cluster/sector/track/whatever went bad is virtually zero.
>
>But if a cluster went bad, then you lost that data anyway.
>you may be lucky if it is a text file or something, you may be able to
>rejoin it, but if it is a music file or Jpg or even software, then it is
>gone forever.
Sure, if it's user data located in the cluster(s) that become unreadable
you're pretty much out of luck no matter what file system you use
(unless there is redundant data -- I'm not aware of any file systems
which attempt to store redundant data on the same physical drive,
although you could probably do it with NTFSv5 if you wanted to -- I'm
pretty sure you could create mirrored partitions on the same physical
drive, but I've never tried it -- The performance would be killer for
writes though)
However, if a FAT16 drive's MFT happens to go, you effectively lose the
entire drive (unless you're willing to review, cluster by cluster, the
entire data portion of the drive to identify files. You won't know when
one file ends and another begins, and you may not even know where the
rest of a file is if you find part (since the drive might be fragmented)
With NTFS, the data is distributed around the drive, meaning that if you
lose a cluster (or even a bunch of clusters together) which contain
metadata, you won't lose as much user data.
>> NTFS avoids fragmentation by attempting to find an appropriately large
>> block of space in which to write a file, vs the typical FAT
>> implementation which writes the file either at the first available
>> space, or sequentially across the disk.
>
>then it do not work, because I find with NTFS, I had to defrag my drive
>a lot more than I do with fat32
Why? Because the fragmentation map doesn't look as pretty, or because
you notice a performance hit?
Don't get me wrong -- There are cases where an NTFS formatted partition
will fragment more then FAT, but this is fairly rare in typical
applications.
When a file is created in an NTFS formatted drive, if the application
sets the size of the file up front, if there is any contiguous free
space on the disk large enough to hold the file, it will be placed
there, and the file will not fragment.
Typical FAT implementations just start writing the file (the start
position varies somewhat, but typically at or near the place where the
last write occurred) without regard to the fact that if the file had
been placed elsewhere on the drive, it wouldn't have fragmented.
The easiest way to get a fragmented file in an NTFS partition is to
create a small file and append to it in a drive where the free space is
highly fragmented.
Also, NTFS will tend to leave free space somewhat fragmented by design.
This is not a bad thing, although it doesn't create as pretty a map in
defragmentation software. The reason is that when a new file is
created, NTFS will tend to place that file physically near other files
in the same directory. The downside is that if a drive is near
capacity, you'll see a huge amount of fragmentation.
>>>>- Native compression support
>>>
>>>Never used it
>>
>> If you ever need it, it's there for you. It can also be a significant
>> performance boost under some cases.
>
>I am not sure how to use it really, since I have never needed it.
>I can not see how any compression can be a performance boost.
I have some VHD files that are around 4GB in size, but compress to 25%
of their original size.
When I copy one of those VHD files the drive only reads 1GB and writes
1GB. If compression was disabled, the drive would have had to read 4GB,
then write 4GB.
In other words, with compression enabled there is only 2GB of disk I/O,
whereas with compression disabled there would have been 8GB of disk I/O.
The other factor is that while CPU speeds have drastically increased
over the past few years, hard drive speeds haven't kept pace. Even if
the goal was simply to read the file (and do something with it other
then just write it, which doesn't require a decompression/recompression)
you can still see a performance boost in some cases.
My laptop's drive spins at 4200rpm, which results in a read speed of
approximately 25MB/s. However, since it has a 3.0GHz CPU which is
largely idle most of the time. It only takes a few percentage of CPU to
decompress a NTFS compressed file which is being read at 25MB/s, so the
resulting read speed for a file which is compressed 50% is roughly
50MB/s.
Imagine this taken to an extreme -- An external USB drive connected to a
PC with only USB 1.1 ports. You'd do a lot better with better
compression then NTFS offers (NTFS compression is optimized for low CPU
use rather then the best possible compression)
>>>>- Better long file name support
>>>
>>>That can be a good idea, but it can also be silly.
>>
>>
>> Since long file names are a reality (And used internally by Windows'
>> default directory names), why piss around storing them in the
>> traditional FAT method?
>>
>Have you seen the way word tries to save its files? The filename is the
>first line of the document, which could be 80 characters long, now that
>is silly. I know you can change it, but it is still silly.
>I try and keep my names as short as possible, since if you go to long,
>then you break the ISO standard on CD.
Sure, but that's not a filesystem issue -- It happens equally under any
LFN-capable file system.
The difference is that as soon as you exceed 8.3 characters, FAT wastes
directory records breaking the filename down into 8.3 chunks.
Admittedly in a multiple-GB drive, wasting a few MB in unused directory
records isn't a big deal, but it's still a stupid design (although a
necessary one, since LFNs were bolted in after the fact -- I can't think
of a better way to do it, other then to store the LFN information as
metadata in a file located elsewhere on the drive -- This would result
in a huge performance hit since that file would be physically separate
from the directory structure, require the drive heads to move)
>>>If I change back to XP, as I am using ME at the moment, I am going to
>>>keep my drives as fat32. at least if anything goes wrong, I can stick
>>>the drive in the other computer and get more chance of saving any files.
>>
>> My sympathies.
>
>Why? I am happy with FAT32, I should never have changed to NTFS in the
>first place, I was warned and ignored it.
My sympathies with regards to WinME.
-- You can get more with a kind word and a 2x4 then just a kind word.
- Next message: DevilsPGD: "Re: Dual Monitor - Stretch Taskbar Onto Both Windows"
- Previous message: Keith: "Permission Problem"
- In reply to: Ad: "Re: Fat32 vs NTFS ?"
- Next in thread: André Gulliksen: "Re: Fat32 vs NTFS ?"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
