Oh, its never M$ fault…NOPE!

Won’t users love that? Reboots every Tuesday. Expect more mayhem in “the registry” and more unbootable PCs running that other OS. It’s all good. Whatever motivates users to switch to FLOSS is good.

http://www.computerworld.com/s/article/9232280/Microsoft_move_hints_at_the_death_of_Windows_service_packs

So users will be getting updates every few days.

Current day OS kernels have virtual address tables at there disposal. Kernel space even uses virtual address tables. This removes the memory manager doing compaction from having todo track down rand location pointers. Applications and all kernel drivers are contained by the virtual memory tables so update the virtual memory tables pointers and you updated all pointers required.

That Exploit Guy
–but instead of doing all that in the middle of the night with a defragmentation tool, you do it every time you write something to a disk. Also, as pointed out in one of comments, the method does not solve the problem where a group of files may need to be kept close to each other, e.g. components for a video project.–

Here is a problem this shows TEG lack of experience and knowledge on real world conditions. A degfragmentation tool in the middle of the night will not ensure that files need for a video project will remain close to each other or in a rapid readable state while doing operations through the day either.

Ext file systems gain from doing at write time is 1 the file is normally already cached so is already in ram. Since its not fragmented in memory normally you can do big block dma operations to dump it to disc if you can find another location on disc to drop it non fragmented.

Writing fragments all over the place is slow and consume more IO operations. Yes its faster to defrag a file that is fragmented than it is it write it fragmented. Less IO operations to write a non fragmented file. Yes lack of write defraging is one of the reasons why NTFS is slower at well.

Its also less IO operations to read a non fragmented file. With inodes in ext they contain the new file size and where the new start point on disc is anyhow. So those write operations are the same fragmented or not.

Even on a ssd not fragmented inside the length of file does require less IO operations to place the file to disc or read from disc.

Files spread all over the disc continual blocks so they can be read in the min IO operations per file cause zero performance impact on a ssd. A file that you have to perform 1 IO operation to read compared to the same size file you have to perform 5 IO operations of course the one you have to perform 5 is slower.

On spinning media. The problem is harder. Since it also comes down to where the other heads are. So if you have 4 files they are all written so that the tracks they are on line up with like the 4 heads the drive has so the drive does not have to move the arm to read the files they will read off faster. Problem is the sector locations the OS sees and the real physical sector locations inside the drive have no relationship to each other any more. So optimising for the disc is now impossible. So you cannot optimise placement of files for spinning media. All you can do is optimise number of IO operations per file. Before you say you can run a program and detect where is fast TEG think about smart sectors that replace dead sectors. Yes even optimised to reduce IO operations to drive the read still might be slow due to head movement to read replaced dead sectors by hard-drive firmware.

Placement optimisation is dead on most spinning media. IO optimisation is all you can do on that type of storage media.

That Exploit Guy is a collage student who basically knows jack about real world conditions. Systems can only perform so many IO operations. Each extra does hinder performance.

–where the Flash memory blocks are abstracted away from the operating system itself.–

Watch some of the videos at Linux conferences from guys who make those abstraction systems. You find that the abstraction system in fact attempts to detect the filesystem on disc so it can detect what sections of disc are really in use and what section it can clean up. The issue is windows does not support the ssd trim command for all ways flash can be connected. So a flash drive by USB resorts to detecting ntfs and fat(so hope you write them how Microsoft does or flash goes nuts). Linux file systems they know they will get trim commands for so don’t embed drivers for reading those.

So yes there is a requirement for the file-system to work cooperatively with SSD. Block alignment stuff ext and older Linux filesystems don’t support yet. Neither does Microsoft.

–B-tree Rule 5: For any nonleaf node: (a) An element at index i is greater than all the elements in subtree number i of the node, and (b) An element at index i is less than all the elements in subtree number i + 1 of the node.

…

B-tree Rule 6: Every leaf in a B-tree has the same depth.
–

You don’t need to break either Rule to go disaster if you are not properly removing deleted entries. You obey those rules in my example for the insert. You just don’t process them on delete any more than marking them deleted.

Build the example I told you todo and watch what happens. Note marked as deleted does not mean when you insert you magically clean them up. It means you balance that delete entries are are still worth while entries.

Windows Registry Hive is a form of dirty b-tree.

A dirty b-tree is balanced like if entries marked delete that insert has not replaced yet are valid possible active entries. So the tree is larger than it needs to be for now but it might be exactly the right size for future usage. Performance gain comes from not cleaning tree is good until the b-tree gets too dirty. How does the dirty b-tree get too dirty when inserts are not replacing the items that have been deleted and start folding out creating more and more levels to the b-tree while there are tones of deleted items in the tree.

Windows hives is a form of dirty b-tree. Where in the rules That Exploit Guy says that a b-tree has to be clean of dead/delete/useless entries. You will find if read the book you are quoting it does not say that.

Most coding books don’t cover the dirty b-tree and its advantages.

That Exploit Guy
–you cannot predict the future–
This is exactly why clean and dirty b-tree’s exist.

Keeping a b-tree perfectly clean of dead leafs might mean you have to be deleting and recreating structors more of then you really should. Like a leaf ends up containing no current entries so you remove it. Problem is what if the next insert wants that leaf straight back. You have just wasted O(log n)+ de-allocating processing operation time doing the delete only to have to reverse it so the insert costs more time..

With a dirty b-tree a leaf with all deleted entries will remain around to be reused by insert at least for a time.

This is what happens when you have a collaged trained with no real world experience optimising b-tree’s. They are not taught at collage about dirty b-trees so don’t believe they exist. Collage trained incompetence also always believe b-trees are always clean so miss handle dirty b-tree by not understanding the importance of compaction operations. Also the fail to read and understand what a b-tree really is. Also don’t know the speed advantages of using dirty b-trees. Used correctly dirty b-trees consume less cpu time over work cycles than clean b-trees. Used incorrectly a dirty b-tree will end up costing you. Basically being a huge idiot at large.

Some databases use a form of dirty b-tree with garbage collection. Something is market deleted its left for so long for a insert to replace it if its not replaced then the removal is processed. Basically why do a O(log n) operation when you don’t have to.

The delete process of a b-tree can get very complex with optimised b-trees. Its all about handling what happens in future using the least cpu time. Most importantly not doing operations in short amount of time you will have to reverse were able.

Microsoft use to provide a tool called regclean that use todo the compaction. Problem is Microsoft added detecting useless keys to it stuff that up and got rid of the tool.

Oldman run a hive backup on your R&D machine I have a sneaky feeling the hive will shrink and result in better performance for you.

Hmmmm, I never considered that. I’d would have to use an oscillioscope to check that.

Which leads me to wonder, how much energy does Windows consume over Linux.

I think its fairly significant, which would lead to a study, to be followed by a press release, citing that Linux is far more green and LEED ready then M$ Windows.

Yes, of course, everyone who utters the word toilet is “fixated” with feces. LOL. Since you take such an unsual interest in this matter, it seems to me that you harbor secret dreams you’d like to act out. Don’t be shy, dougman. There are women whom you can pay for such services.

Many thanks for the reply.

As far as your comment…”Would you much rather show this to Robert Pogson?”

I assumed he would see it and read it anyway!

linuxaria:

‘With Linux’s ext3/4 these are actually designed to prevent fragmentation, they’re given a size by ratio…’

As I said, this is generally a pointless avoidance method as there is simply no effective ways to estimate how much a file will grow in size, i.e. you cannot predict the future.

‘… and each time the file grows beyond that space it’s moved somewhere else and given a larger “buffer zone”.’

This is just compaction done in a bizarre way, and it comes with all the problems associated with compaction in general – I/O penalty for reallocation, pointer/metadata updates, etc., but instead of doing all that in the middle of the night with a defragmentation tool, you do it every time you write something to a disk. Also, as pointed out in one of comments, the method does not solve the problem where a group of files may need to be kept close to each other, e.g. components for a video project.

‘With a windows defrag they happen per accident and the size can be anything from one allocation unit (usually 4096 bytes) to many gigs. There’s no real “plan” behind it, and it doesn’t matter how many times the file’s grown or what its size is. It’s even possible to have absolutely no space between files, so you end up with a FAT like scenario.’

1) Assuming facts not in evidence.
2) See above.

webupd8.org:

Would you much rather show this to Robert Pogson?

rtcmagazine.com:

Write amplication has fundamentally nothing to do with fragmentations in the file system but with the wear-leveling algorithm [1] where the Flash memory blocks are abstracted away from the operating system itself. NTFS is strictly not designed to manage SSDs directly and there is no reason to expect that mere, routine defragmentation is adequate to solve the problem in any way.

[1] See here for the difference between dynamic wear-leveling algorithms and static wear-leveling algorithms and discussion on certain design issues.

I suppose that’s possible if a CPU running GNU/Linux puts less draw on the PSU but I would not count on it. I have exploded more capacitors than I should have and none of them “came back”. An electrolytic capacitor often fails by gradually losing capacity but too often they explode or short. Nothing much will fix that except a new motherboard or a soldering job.

My best ever was an attempt to increase the accurace/stability of a power supply for the magnet of a cyclotron. We increased the gain but went too far. The thing began to oscillate and the charging and discharging of the 100KW PSU heated the capacitors rather quickly… My boss was close to them and I was half a second too slow to hit the panic button… Fortunately they were “aimed” upwards.

Another good one happened in the middle of a lesson. I was leaning on an ATX PC when its PSU exploded… Instantly I changed the lesson to swapping PSUs and recording the smell for future diagnostic events. What are the odds? One in a many million, I suspect.