File Fragmentation 7081
Aragorn On my system, in aic7love.h I see:* * The maximum amount of SCB storage in hardware on a controller. * This value represents an upper bound. Due to software design, * we may not...
Peter T. Breuer
Peter T. Breuer Well some buffering, including read-ahead and write-behind (and therefore, reordering of actual hardware transfers to and from the disk platters) is done in some hardware out there. This is certainly...
Believe me, I understand fragments. Yes, I understand them the MS-DOS way, I understand them theoretically, and I see them on my ext3 parbreastions. I don't study them actively, but I understand them. What you describe is done at the hardware level, but the file system has control over where the fragments are placed, how the files are distributed on the hard disk. If *that* was done in hardware, we'd have no need for software-implementations of file systems, like ext2, NTFS, etc.
The way we as users look at files, you are right, there is no next fragment if the file system does its job well. That doesn't explain the inner workings. Saying the disk read-write head sweeps the surface of the platter explains hardware that I already know (there are many algorithms that do this), and putting data into buffers and signalling interrupts is again stuff I already know (most modern-day hardware does this).
Currently, I think your explanation on clustering blocks is the best one suited for my original question. I appreciate the time you've taken to help me understand it.
Thanks again,
Cliff Hewitt
Linux groups from Newsgroups