Re: FAT32 or NTFS?
From: DILIP (dilipr_at_#*&!%l.com)
Date: 05/12/04
- Next message: kurttrail: "Re: TEST"
- Previous message: Alex Nichol: "Re: Running DOS on Windows XP"
- In reply to: cquirke (MVP Win9x): "Re: FAT32 or NTFS?"
- Next in thread: Al Dykes: "Re: FAT32 or NTFS?"
- Reply: Al Dykes: "Re: FAT32 or NTFS?"
- Reply: Al Dykes: "Re: FAT32 or NTFS?"
- Reply: cquirke (MVP Win9x): "Re: FAT32 or NTFS?"
- Messages sorted by: [ date ] [ thread ]
Date: Wed, 12 May 2004 19:42:19 +0530
> >The jpegs will affect the equation here. The average size of a picture,
> >depending on its source may be anywhere between 150KB for web photos to
> >2-3MB for those downloaded from a digital camera. If we consider the
former,
> >it would not be incorrect to assume that the wastage in such a scenario,
> >with many small files, would be considerable
>
> Well, do the maths. If files are 150k, and cluster space is 32k
> rather than 4k, then the biggest wasteage would be 32k-4k = 28k per
> file. Assume actual wastage is half that, i.e. 14k, per file. That
> boils down to under 10%; significant, but not carnage.
10% wastage on 10 volumes is one whole hard disk wasted. Significant? Hell
yes, it increases costs! You should've known that considering it's the job
you do.
>
> OTOH, if it's more like 2M per file, this drops to an under 0.7% shrug
>
> >As suggested by your figures about start menu shortcuts.
>
> Those are 500-*byte* files, not 150 000 - 2 048 000 bytes :-)
> What will really waste space would be IE web cache...
>
> >Other considerations of the original poster were "resilience, recovery,
ease
> >of repair".
>
> Yep - and once again, NTFS isn't quite what it seems.
>
> >resilience --- As far as FAT partitions go, don't forget to wave goodbye
to
> >your all data and the OS, when the disk becomes over full. This has
happened
> >to me once already.
>
> Haven't seen that, unless you are using disk compression.
Well I have seen it. The data is not recoverable, because it simply gets
corrupted. Data recovery software does little to recover completely corrupt
files.
Read up on
> the shuffling NTFS does when it fills up... I can see the same sort of
> widening of critical windows there, as it re-balances between MFT and
> data space. Problems may also arise when software that assumes
> limitless memry (as bounded only by free swap space) hits the wall.
I know about the shuffling it performs. It is not as terrible as you make
it seem. For the benefit of the others reading this thread - Basically 12%
of the initial part of the HD is set aside initially (saving the 16
metafiles) for the MFT to prevent fragmentation (it's not even used at this
point of time). As and when data is required, the MFT is adjusted. Nothing
very "problematic" or sinister in there. I have had an NTFS volume with as
less as 25MB free out of 10GB running with absolutely no problems over a
long period of time.
>
> >In such situations, it becomes tricky to save the OS, and depending on
> >the seriousness of the crash, data loss possibilities are considerable.
>
> I've done a lot of data recovery on FATxx, and that's the point; it is
> possible to recover lost data in such cases.
Lost data OK. How about corrupt data.
>
> >recovery and ease of repair --- NTFS file systems don't need a scandisk
add
> >on per se, simply because they don't need one. Data verification
> >technologies imbedded in the file system ensure that data is only written
on
> >to the disk, when it is verifyible. If it cannot be read back, the
> >transation is simply rolled back.
>
> Read: The damaged data is stimply and irreversably destroyed.
The data remains intact. I have had power failures while working with
files and defragging. The files remain - albeit at the cost of the
changes. No issues there. I don't know what and why you're trying to
project this wrongly.
>
> This is what I mean; NTFS "doesn't need" Scandisk simply because it
> behaves as if Scandisk was running all the time, with the most
> ruthless trade-off between your data and file system integrity.
I don't understand this statement. Cut the flowery language and start
explaining.
>
> That is NOT what I consider "data safety".
>
> >Which brings me to this - In an NTFS file system, a transaction is
> >either performed completely or not performed at all. It's 1 or 0.
>
> Exactly. Some of us would prefer to recover truncated or partial
> data, but you don't have that option with NTFS.
>
> >Consider a power outage occuring during a defrag process
> >of a FAT drive. The possibilities of errors is high on a FAT partition
>
> Sure; that alerts you to what files are damaged - but at least you
> have a chance at recovery of partials. With NTFS, it's simply gone
> without a trace, and no way of getting it back.
>
> >One more thing, you mention that "the tiny file data would be held
entirely
> >within the directory entry metadata." Wouldn't this be stored in the MFT?
> >metafiles as such, (as I have read anyway) refer to the files created
when
> >an NTFS partition is first created (sixteen), and contain volume &
cluster
> >information; strictly speaking unavailable to the OS. Under NTFS, there
is
> >no specific difference between a file and a collection of attributes,
>
> Specifically, file data and attribute metadata are held in the same
> way, as streams. Streams are effectively cluster chains containing
> content that hang off a dir-level entry; a structure that's familiar
> from working in PICK.
>
> >including data contained in the file itself. When the space required for
all
> >the attributes is smaller than the size of the MFT record itself, then
the
> >data attribute is stored within the MFT record itself. Please clarify
what
> >distinction you consider between MFT and metadata.
>
> By metadata, I was referring to that within the directory level, not
> within the streams. But you do raise an interesting point - that
> bloated metadata are not "free" if it effectively means two or more
> cluster chains to look at in addition to the dir level.
>
> Earlier on, someone made the claim that NTFS keeps redundant copies of
> the dir structure. What I read suggests it's only the first few
> entries that are held in that way - in effect, a similar result as
> predictable locations for these core structures as applies in FATxx
> (where this knowledge is the "redundant copy").
I don't know why you are propagating falsehood. Maybe because by
implementing FAT32 you get more problems to attend to, and hence more
business. Your site is as vague as the rest of your posts (I had not seen
it earlier) and the statement that NTFS is for people who need to hide data
more than recover it is just plain condescending. Don't you understand that
even a basic org would want to implement best practices; public and private
data, templates and files.
Perhaps that's why you and your biz will always cater to small/medium sized
clients. Unless you think big, you don't get big. As far as the sig goes,
regarding certainty, an uncertain person or one in two minds (with a
disclaimer hanging on his neck) will never take crucial decisions - It shows
lack of confidence in yourself. Essentially, your advice could be viewed as
a dis-service to society and the computing fraternity in general, since
you're stuck in a generation no one really cares about.
-- Replace the obvious with "hotmail"
- Next message: kurttrail: "Re: TEST"
- Previous message: Alex Nichol: "Re: Running DOS on Windows XP"
- In reply to: cquirke (MVP Win9x): "Re: FAT32 or NTFS?"
- Next in thread: Al Dykes: "Re: FAT32 or NTFS?"
- Reply: Al Dykes: "Re: FAT32 or NTFS?"
- Reply: Al Dykes: "Re: FAT32 or NTFS?"
- Reply: cquirke (MVP Win9x): "Re: FAT32 or NTFS?"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|