Deutsch English Français Italiano |
<vm9mk9$36phj$1@dont-email.me> View for Bookmarking (what is this?) Look up another Usenet article |
Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: Paul <nospam@needed.invalid> Newsgroups: comp.os.linux.advocacy,alt.comp.os.windows-10 Subject: Re: Microsoft to force new Outlook on Windows 10 PCs Date: Wed, 15 Jan 2025 20:15:50 -0500 Organization: A noiseless patient Spider Lines: 126 Message-ID: <vm9mk9$36phj$1@dont-email.me> References: <1VcgP.54962$XfF8.39289@fx04.iad> <vm1itg$1f1ma$3@dont-email.me> <vm40cl$21e8l$2@dont-email.me> <6h1bojt7kdp4d5euq0f78rtuvqpg7edc3e@4ax.com> <HHghP.135123$5c34.129668@fx47.iad> <la6bojl7t4686ll2teomlj0ig70ma8o8c8@4ax.com> <Q3hhP.45732$nlJ1.37298@fx41.iad> <ru7bojpl0j6ot182uuhhvrakcflqsadi30@4ax.com> <vm4kho$28of2$1@dont-email.me> <vm7m77$2rnlk$2@dont-email.me> <2jlfoj1ik2eptf57n2vtpfcsjhnmjc2pd8@4ax.com> <luqtrgFijddU4@mid.individual.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Injection-Date: Thu, 16 Jan 2025 02:15:53 +0100 (CET) Injection-Info: dont-email.me; posting-host="fa538bd1421207436cc03ef4b5aae205"; logging-data="3368499"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/Bj6rTJbF346Q2DOvMWFTF+BfG5qge3jE=" User-Agent: Ratcatcher/2.0.0.25 (Windows/20130802) Cancel-Lock: sha1:YxAtvJBkIoSxr9UrpCy7Vhf9BRw= In-Reply-To: <luqtrgFijddU4@mid.individual.net> Content-Language: en-US Bytes: 7175 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.gif These 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.gif Whereas 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