On Wed, 1/15/2025 6:14 PM, rbowman wrote:
On Wed, 15 Jan 2025 10:40:14 -0500, Joel wrote:
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Tue, 14 Jan 2025 03:09:43 +0000, Manu Raju wrote:
>
Linux gets bloats every two weeks and some people like it! I don't
and so I solved the dilemma by moving to Windows.
>
Windows is the one that needs regular defragging and running of dodgy
hacks like CCleaner etc. Linux does not.
>
>
I never needed that with Windows, but reinstalling ended up happening,
from time to time.
I haven't bothered with dual boot in a long time but the problem with a
Windows install that had been running for any length of time was it left
pecker tracks all over the HDD. You had to defrag to get enough free
storage all in one place.
Not in evidence.
The writer tends to maintain a couple of zones. Some
of the larger files seem to end up above, a lot of the smaller files
are below. The NTFS file system has a "reserved" area, which
interferes with operation of the partition, as the partition fills up.
This is why, quite frequently, patterns which should not create fragments,
result in "yellow" in a partition that should not have been there. The
reserved area starts at a certain size, and the amount of reservation
changes as the space fills up. For people who like their files packed
like sardines, they are most put out by this development :-)
[Picture]
https://i.postimg.cc/YCDLWmkB/Windows-SSD-fragmentation.gifThese sample OSes are all on SSDs, where the rule is, you do not defragment them.
(SSDs get TRIM, instead.) The OS still has the right to defragment them,
if slow-COW conditions are detected. That should not have happened to these.
The top two panes are from a newer AMD system. The bottom two panes
are from the 4930K ten year old computer.
The "red line" is an item that cannot be moved by the defragmentation
tool used to make these pictures. I use the tool for taking pictures,
when these particular devices are involved. The fragmentation means
nothing (at this light level of fragmentation) to performance.
The "red line" can also not be moved by the windows Disk Management
"shrink function". It can shrink to about 50% of the original partition
space, when a partition does not have a lot of files. In the "red line example"
at the bottom, the Disk Management will shrink to 50%, while other methods
will shrink to 33% or so. The shrinking process stops when it hits
that red line.
Generally, if the program doing the shrink is doing it in an offline
fashion, that gives much better control than when the Windows one attempts
to do it online ("hot" shrink). Thus, gparted can shrink the red line pane,
to the 33% number without too much delay.
It's the same with zeroing functions. The Windows third party tool is
"sdelete64.exe" and it zeros a partition while the partition remains
mounted. Whereas Linux "zerofree" does this same kind of function
on unmounted partitions.
One reason the Windows people like to show off with their
functions such as shrink, is they're implemented with the
data-safe defragmenter API. Which was originally written
by a third party, but was good enough for Microsoft to buy
it and put it in the OS as a library. Everybody and his dog
uses that library. It would be "extra work" for somebody
to write an offline version of the tool instead :-) The tool
that took the green pictures, also uses that library.
There's still plenty of room to work on those partitions.
On this sample data partition, this shows how the writer
is filling in the holes, and the two "air holes" are likely
a result of the reserved space handling. Again, being on an
SSD, no attempt has ever been made to defragment the thing.
And the green, is files which are contiguous and their
clusters are in cluster-order. The yellow ones are "largely ordered",
but as soon as one cluster goes out of line for such a file,
the whole file will be yellow. Considering "how evil" fragmentation
is, you don't see a lot of fragmentation there.
[Picture]
https://i.postimg.cc/wjRgwtLp/Sample-Data-Partition.gif*******
This picture was done seven years ago. The top two panes are
performance on a RAMdrive. Running a checksum program on
a large file, one with a lot of fragments, one with no fragments,
there is hardly any speed difference to the performance of the
checksum program when we are measuring the file system stack
penalty for fragments.
[Picture} Top two panes = RAMDrive, bottom two panes = SATA SSD
https://i.postimg.cc/ry7VnwF7/fragmentation.gifWhereas the bottom case, the seek time on an SSD could be 20 microseconds
or so. And then the SSD speed does have an impact on the read rate of
the checksumming process. When doing these experiments, you do a bit of
fiddling first to clear the System Read cache.
No attempt was made to run that on a HDD, as the results would
be quite bad on an HDD. The rattling noise that would make, would
get on my nerves.
And the pattern on the storage there, was done with a purpose-built
pathological tool. I wasn't doing my income taxes to make that pattern.
Regular disk usage does not fragment like that.
Is Windows cheating to make relatively good-looking partitions ?
It's possible. I do not normally see suspicious patterns of the
drive light, hinting that some rearranging is going on. The write
algo has changed since WinXP days, whatever it is. Leaving holes
in the cheese, seems to have something to do with later placing
small files in the holes.
Paul
Re: Microsoft to force new Outlook on Windows 10 PCs
Re: Microsoft to force new Outlook on Windows 10 PCs