Lubos Lunak said the following on 02/15/2010 12:02 PM:
On Monday 15 of February 2010, James Knott wrote:
Lubos Lunak wrote:
As demonstrated also in this thread, there is a widely accepted myth that defragmenting is completely useless with Linux, and as such nobody has been really bothered enough to write any reasonably usable generic tool.
Given that modern file systems are fragmentation resistant, please explain how fragmentation is a problem on Linux.
Well that isn't a explanation. In fact the guy admits he's a KDE developer and not a kernel hacker. I was, though not any more. kernel hacker that is. Disk drivers and file systems were my focus back then. Different technology, UNIX, not Linux, but some principles still hold. One principle is that the old sequential file model of Dennis's UNIX hasn't held for a long time. Shortly after Virtual Memory came along everything got, well, "mapped". It doesn't matter what the file is, lirarby, executable, or data, it mapped into virtual memory. This makes the old V7 idea of code/data space adb disk buffer space meaningless. It also makes a lot of thigs faster 'cos there's no copying from "disk buffer" to the applciation data space if tyo write the code properly. You just 'map'. Along with all that VM we got right of the idea of fixed tables in kernel of the maximum number of open files and stuff like that. So now you can have a bit of code that opens every file KDE might need,becuase the real cost of a file isn't the fragmentation, its the resolving the name path, getting the i-node and and all the tables set up ready to read it. THAT is why KDE starts up slowly. Not reading in the libraries, opening all those files. If you want to improve the performance, then don't worry about defragging the file contents, the extents, make sure that the name caching works well and those i-nodes are clustered together. That's going to matter a lot more than whether the files are contiguous extents rather than merely being in the same cylinder group. Once all those files are opened, all those relevant *.so files, you do't need to do anything more. They are now mapped into virtual memory. If some application code refernces a linrary routine then that VM page is referenced. If its not in memory - page-fault. Like the old saw says, "Virtual memory means virtual performance". So add memory and as the pages fault they come in from disk. Opps! They get hit all over the place, so maybe a complete *.so doesn't all get read in at once, the whole extent. Heck, libc-2.9.so is 1419604 bytes and has over 1400 library functions. Its unreasonable to expect it to be read in to VM as a single extent. Just map it and page in what's needed. never mind where it on disk. That being said, its nice if the head doesn't have to move too much. That's what cylinder groups are for. Modern disks are such that a head can cover a few cylinder without having to move. Which leads to the idea that a few smaller spindles may be better for overall performance than one enormous dive. Well, OK, its not the old PDP-11/45 or a VAX where the disk IO can chain requests and a single controller can perform seeks on 7 other drives while doing a transfer from the one the seek has completed on. All without CPU intervention. So I wish you joy with your defragmentation code in XFS and ext4, and joy running your defragmenters. I'm sure you'll waste a lot, lot more time than you'll save. Me? I'll buy a faster disk every few years. Upgrade my server to do striping. Buy a laptop with a LOT more physical memory. Spend my time playing with the cats, sitting in the sun with a cool drink, talking with friends, cooking new dishes. -- The spirit of resistance to government is so valuable on certain occasions that I wish it to be always kept alive. It will often be exercised when wrong, but better so than not to be exercised at all. --Thomas Jefferson -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org