Skybuck's Universal Code 5 (The Native Version)

No he isn't. You're looking in that cracked mirror again, DIMBULB. It was standard practice. Rip open the packaging on a new drive, and copy of Windows. Install it, spend at least a half hour defraging that new install, then install the drivers and box everything up for the customer.

And exactly what do you claim to have to have elucidated here?

What kind of freaking idiot tries to access the disk without either using or understanding the file system?

Isn't it obvious? Skyduck has proved that you can have an IQ of ice water, and still post crap to USENET.

You're full of s*it.

Usenet is NOT an acronym, you retarded f*ck. You are in the same boat with the SkyTard. 100% of your posts are utterly worthless, and should be ignored.

Somebody that tries to access the disk you retard.

Bye, Skybuck.

"Skybuck Flying" wrote in news:cdf7d$47ca6198$541983fa $ snipped-for-privacy@cache2.tilbu.nb.home.nl:

potkettlebuck

As in file open(), seek(), read(), write(), close(), create(), or delete() calls through the file system? Or do you not have an OS or file system at all?

It must have been one of his sock puppets that's filtered.

He feels slighted over something, but people like him are too high strung. He might be Phil's brother, down under?

Perhaps he does feel slighted. It would be better if he was using his own name and told us what the heck he's so spun up about. He obviously knows some electronics but I can't match him up with and of the regulars.

Yes. On brand new installs.

The installation process uses the file system the same as anything else. Since the allocation process is FIRST AVAILABLE as soon as two files are written and the first one is deleted there is a hole and fragmentation gets started. And there are a lot of files loaded and deleted during the installation process. The only way that the disk would not be fragmented after an install is if the installation process specifically ran a defrag at the end. I have never noticed this happening.

A possible allocation algorithm to minimise defragmentation is to always allocate into the largest contiguous unused space. This minimizes the possibility of fragmenting a new file and gives the greatest chance that a delete will open up a larger space. This is very effective in an environment where there is a lot of temporary files created and dropped. Unfortunately, this is not the way Windose works.

And GUARANTEES fragmentation.

See Archi and Bios calls.

Bye, Skybuck.

This is less than perfect. It tends to spread the files uniformly over the surface of the disk. This makes for many small gaps and longer seeks on the average between files.

These days, it is likely that allocating into the first /last gap bigger than a few gig would work better.

Pushing the allocation towards at least one end would tend to keep the free space together.

Yup. No allocation scheme is going to be perfect in all environments.

I'm not sure I buy this, but I would guess it would depend on the volatility pattern. A workstation doing heavy wordprocessing would have a completely different volatility pattern to a DB Server. I know from intimate experience that the 'largest free' algorithm works best for allocating virtual storage paging buffers. I have extrapolated that to other highly volatility allocation schemes with great success.

A low turnover usage pattern would no doubt require a different scheme. A static or nearly static database would just need to ensure that it was allocated in one piece at the beginning. Of course then it is the scheme used by the DB engine to sub-allocate its available table space that becomes critical. Again, what is the internal data usage pattern? High volatility, or what?

But notice that I did say the 'largest free' algorithm worked best in a high volatility environment.

I tend to disagree with this. At first I was going to say that it is a reasonable adjustment to my 'largest free' scheme, that takes advantage of any large holes that happen to exist, and keeping allocated data down one end sounds good. But as I thought about it I realised that any holes of 'a few gig' wouldn't stay that way, and you would quickly be left with holes of somewhere just under 'a few gig' with no real prospect of getting them back any time soon. And the allocated footprint would continue to grow towards the other end anyway. Then again, I guess it would depend on whether we are talking true temporary files or generation datasets.

Clearly a adaptive approach based on file size and anticipated lifetime would be best, but I can't really see how we could necessarily tell in advance how big a file is going to be. I know some DB engines can have different table spaces for large versus small buffer size tables; high volatility versus low volatility; and the like.

I guess you can ask Windows for a "temporary file", but "temporary files" still need to be explicitly deleted. If you could also mark them to be "expired" when the process that created them is shut down, and if we could specify the location (partition?) for temporary files, then we might have something.

There is a lot of mental gymnastics going on here. Like my calculus teacher use to say: "the intermediate steps are left to the student as an exercise." :)

Or "optimized" after each write.

File systems have a very mixed volatility. Some files remain forever. These tend to break you total space apart.

Some software tends to expand its allocation is hunks. Many years back I work with a file system IBM used where one out of every N records was left empty. This allowed a quick insert of a new record without having to allocate a new block. When there was no gap to be found, it backed down to allocating a block. It put the new record more or less in the middle of the block. At some point it had to reshuffle to whole file. Basically it defragged the file.

Yes I saw that limitation.

The progress towards the far end would be slower. If the files are always under 1G you won't end up fragmented until the disk was very nearly full. This small difference in when the fragmentataion starts is all the advantage I claim for the idea.

I wonder about that though.

Maybe this was true for old harddisks back in those days...

But for todays harddisks ?

Would they really fail ?

Doubtfull but ok...

Bye, Skybuck.