On my continuing obsession with squeezing every bit of performance out of this system… They say that Linux filesystems don’t get fragmented. I never understood this. It’s apparently smarter about where files are placed. But still, frag-proof? If it was that easy, other filesystems would have figured it out long ago too. I figured that the explanation was just over my head. In reality, the “explanation” is that it’s a myth.<\/p>\n
\noxygen bin # fragck.pl<\/a> \/home<\/b>\n2.19458018658374% non contiguous files, 1.03385162150155 average fragments.\noxygen bin # fragck.pl \/var\/log<\/strong>\n56.3218390804598% non contiguous files, 28.9425287356322 average fragments.\noxygen bin # fragck.pl \/var\/www\/<\/strong>\n1.45061443222766% non contiguous files, 1.05527580153377 average fragments.\noxygen bin # fragck.pl \/etc<\/strong>\n2.18023255813953% non contiguous files, 1.05450581395349 average fragments.\noxygen bin # fragck.pl \/var\/lib\/mysql\/<\/strong>\n16.5424739195231% non contiguous files, 2.93740685543964 average fragments.<\/blockquote><\/pre>\nThe results kind of make sense: \/var\/log is full of files where you’re constantly<\/em> appending a line or two to various files, so it only stands to reason that, if the filesystem isn’t very<\/em> careful, fragmentation would build up. The other one is \/var\/lib\/mysql, where MySQL stores its data. It’s the same deal as \/var\/log, really, in that it’s continually adding files.<\/p>\n
\/var\/log\/messages, the system log file, is in 75 pieces. Its backup, messages.1.gz,was in 68.<\/p>\n
Realistically the performance hit is negligible. It’s not like a core system file is in hundreds of pieces. (Like, say, the paging file!) \/bin has very low fragmentation. Log files can be fragmented an not impact anything. (Except my OCD.) Although I am concerned about MySQL’s data stores building up fragmentation. In theory I can bring the database down and shuffle the files around, but it’s probably best left alone right now.<\/p>\n
Fortunately, there’s hope… By moving a file to another partition, you cause it to move physical locations. Something like mv messages \/tmp\/ramdisk && mv \/tmp\/ramdisk\/messages .<\/tt> will cause the file to be rewritten. (Granted, this particular command was an awful idea: syslog-ng keeps \/var\/log\/messages open, and doesn’t like it when the file randomly disappears. The fact that it was only gone for a split-second doesn’t change the fact that the files location has changed.) Although don’t get too excited about this: for some reason, fragmentation sometimes ends up worse! access_log was in 60 pieces. Now it’s in 76.<\/p>\n
I’ve also heard it said that some fragmentation isn’t necessarily a bad thing: a few files close together on the disk with light fragmentation is better than frag-free files on opposite ends of the disk. But that doesn’t satisfy my OCD. I guess the moral of the story is to not muck around too much with things. Or, “if it ain’t broke, don’t fix it!”<\/p>","protected":false},"excerpt":{"rendered":"
On my continuing obsession with squeezing every bit of performance out of this system… They say that Linux filesystems don’t get fragmented. I never understood this. It’s apparently smarter about where files are placed. But still, frag-proof? If it was … Continue reading