In comp.os.linux.advocacy, 7
<website_has_email@xxxxxxxxxxxxxxxxxxxx>
wrote
on Tue, 10 Apr 2007 20:17:10 GMT
<ahSSh.9002$NK2.5101@xxxxxxxxxxxxxxxxxxxxxxxxxx>:
> The Ghost In The Machine wrote:
>
>> In comp.os.linux.advocacy, 7
>> <website_has_email@xxxxxxxxxxxxxxxxxxxx>
>> wrote
>> on Tue, 10 Apr 2007 18:55:10 GMT
>> <i4RSh.8925$NK2.5524@xxxxxxxxxxxxxxxxxxxxxxxxxx>:
>>> Asstroturfer Erik Funkenbusch wrote on behalf of micoshaft corporation:
>>>
>>>> On Tue, 10 Apr 2007 04:44:33 +0100, Roy Schestowitz wrote:
>>>>
>>>>> On a related note, Vista still does not handle de/fragmentation
>>>>> automatically.
>>>>>
>>>>> The fastest way to defragment your hard-drive
>>>>>
>>>>> ,----[ Quote ]
>>>>>| Many are saying that Microsoft said it is unnecessary to defragment
>>>>>| NTFS. While that may be true, many are noticing an increase in
>>>>>| performance once they defrag their system, including myself. This
>>>>>| article is a tutorial on how to speed up the defragmentation process,
>>>>>| not one that is asking you to defragment your drive if you don't think
>>>>>| you need to. To defragment or not to defragment is entirely up to you.
>>>>>| Sorry for all those confused.
>>>>> `----
>>>>>
>>>>> http://vistarewired.com/2007/02/15/defragment/
>>>>>
>>>>> It is amazing that after 5-6 years of work, the O/S is still unable to
>>>>> manage its own filesystem properly. To an enterprise, this means wasted
>>>>> time. People do not do what they ought to be doing, which is to do real
>>>>> work (rather than reboot, defrag, and sometimes disinfect/wipe).
>>>>
>>>> Since the "Defend Roy at all costs, no matter how much he lies" or the
>>>> "Object to anything Erik says no matter if he is right or not" patrols
>>>> will quickly come to Roy's defense I will point out explicitly the ways
>>>> Roy has lied here:
>>>>
>>>> 1) Nowhere in the article does it claim that Vista can not automatically
>>>> defrag it's drives. Roy made this up. Completely.
>>>>
>>>> 2) Vista does in fact automatically defrag it's drives. The defrag
>>>> process, by default, runs after installation, and then, again by default
>>>> is
>>>> set to run at 4am every sunday. This is the default configuration. If
>>>> you don't believe me, read this:
>>>
>>>
>>> BWAHAHAHAHAHHAHAHAHAHAHHAHAHAAAAAAA!!!!!!!!!
>>>
>>> What's 'defrag'?
>>>
>>> Clippy doesn't enter into correspondence on what it does and why.
>>>
>>> Help me, my Linux computer doesn't seem to that feature.
>>>
>>>
>>
>> I've wondered about this on occasion. Obviously, Windows
>> filesystem defragmentation -- it's either a gigantic design
>> flaw, inherited from DOS's FAT failings, or a feature;
>> I think it's a mix of the first two -- is a fact of life,
>> even in Vista. (That Vista automates the process is a
>> tradeoff: is it better to fix the failings, or to bodge
>> something that works around them? UNIX(tm)/Linux 'find'
>> and 'locate' are themselves a bit of bodging, though 'find'
>> is far more general and has been around since the 1970's,
>> and 'locate' is the observer side of the 'locate/updatedb'
>> system, which scans the entire disk on a repeated basis
>> (once every day or so) to build a file list. It's a
>> tradeoff: if a system's idle it might as well do something.
>> I'm not sure about beagle/beagled yet though it's an
>> unobtrusive puppy at present -- and hasn't really made
>> any sort of mess on the carpet in my mind yet :-) .)
>>
>> For its part Linux has defragmentation built-in, at least
>> AFAIK, into the filesystem block/inode allocation methods,
>> and the grouping methodology therein. It probably depends
>> on the filesystem.
>
>
> Defragging is practically non-existent until the drive
> begins to get really full. The reason is the clever way
> files are stored eliminating the need to defrag.
> Google for it - there is atleast one neat article out there that describes
> this clever system.
>
A simplified explanation appears to be at
http://geekblog.oneandoneis2.org/index.php/2006/08/17/why_doesn_t_linux_need_defragmenting
Interestingly,
http://www.kdedevelopers.org/node/2270
appears to be of a different opinion, though neither
mentions issues such as rotational latency -- for a 10,000
RPM drive that makes an average of 3 ms difference, if
the next sector's halfway around the disk at the moment
the program wants to read it.
Both are wrong, to a certain extent -- as it's not Linux
that's managing the problem; it's one of Linux's modules,
which could (with a little work) be plugged into FreeBSD,
HURD, or even Windows.
Neither one also mentions -- though it's probably not all
that relevant -- the outright lying most interface cards
do to the CPU regarding disk size. How many disks have
255 heads? That would be a pancake stack more than a
foot in length, assuming 5 mm platter-to-platter spacing.
(And I think they're slightly thicker than that.)
In fact, I believe ext2 has been plugged into all three;
certainly Win95 had "fsdext2", which was buggy but functioned
after a fashion (it was of course a third-party add-on),
allowing Windows to read ext2-formatted drive partitions.
For its part FreeBSD has some interesting executables in
/usr/sbin for mounting "foreign" partition data types.
http://www.linuxquestions.org/questions/showthread.php?t=543142
mentions the notebook analogy, which is probably why ext2
et al don't need defragging; if a file extends the data
clusters in that file can sop it up until the group (or
"notebook page" in the analogy) is full. The journaling,
which the module intelligently implements, also helps,
as the write is deferred until later, when the module can
intelligently decide where to put things (and has an idea
on how big said things are likely to get).
There's also the issue of file fragmentation versus
data ordering. The first refers to how many contiguous
pieces a single file might have scattered around the disk;
the second is an issue for applications that need to read
several or many pieces of data, scattered around various
files and directories.
The best file defragmenter won't help a whit if it puts
the file data in the wrong order, :-) even if the files
themselves are contiguous.
Tools also contribute to the lack of a need. I'll admit
I'm far from certain what the state of the art is here
at this point, but in Linux tools such as make are more
likely to be used, and make isn't horribly intelligent
when it comes to logging -- which might be a plus here as
one can simply type "make" and usually generate a lot of
little files -- .o files, libraries, executables, and other
such -- which are almost guaranteed contiguous, are usually
fairly small, and might even be reasonably clustered (since
they are generally created at more or less the same time).
The log, such as it is, is in memory (a scrollback buffer,
perhaps), but not in the filesystem, unless the user puts
it there with a redirect -- and it might be in /tmp, which
is most likely a different filesystem altogether.
Ant is about the same, in the Java world.
I'm not sure regarding Visual Studio, but it appears VS
has at least one logging file, which it leaves open during
builds. That way lies fragmentation madness. It doesn't
help that the underlying filesystem doesn't manage the
problem well -- but I'll admit I've not done a lot of work
in Windows lately, so haven't a clue as to how badly WinXP
fragments now. There's also .pch and other such files,
which appear to be work files of some sort used for
optimization of the build -- and fragmentation of the disk.
The implementation used in Linux isn't perfect, and
benchmarks might show some flaws therein -- but it's a
far sight better than Windows.
--
#191, ewill3@xxxxxxxxxxxxx
Warning: This encrypted signature is a dangerous
munition. Please notify the US government
immediately upon reception.
0000 0000 0000 0000 0001 0000 0000 0000 ...
--
Posted via a free Usenet account from http://www.teranews.com
|
|
