Chris's Wiki :: blog/solaris/InplaceDefragmentation Commentshttps://utcc.utoronto.ca/~cks/space/blog/solaris/InplaceDefragmentation?atomcommentsDWiki2006-09-13T14:38:45ZRecent comments in Chris's Wiki :: blog/solaris/InplaceDefragmentation.By Chris Siebenmann on /blog/solaris/InplaceDefragmentationtag:CSpace:blog/solaris/InplaceDefragmentation:50d4c7aead8c8a4a4ac049d78950d46d8017c31cChris Siebenmann<div class="wikitext"><p>Any sane FFS-derived filesystem, UFS included, should completely defragment
itself when everything is <code>rm</code>'d; the block (and inode) freelists are just
bitmaps, so empty is empty.</p>
<p>(Also, there's a certain amount of experimental evidence, in that we tried
it and it seems to have worked. Certainly the IO rates on that filesystem
are significantly up from the pathetically low numbers they were before
we did the defragmentation.)</p>
</div>2006-09-13T14:38:45ZBy Dan.Astoorian on /blog/solaris/InplaceDefragmentationtag:CSpace:blog/solaris/InplaceDefragmentation:0c46224dde11fa47380c56e95ed73a1a7c861ed7Dan.Astoorian<div class="wikitext"><p>Ah, but I never said anything about making a new filesystem--only creating a new mirror, using the device of the detached submirror. (Where I said "mount and clear the filesystem", you can still do this by <code>rm</code>'ing everything except <code>lost+found</code>.)</p>
<p>However, I should point out that I've never personally used this method to defrag a UFS filesystem. I don't know enough about the internals of how it fragments blocks to be confident that <code>rm</code>'ing all the files is sufficient to defragment it, so I've always preferred the pave-over-the-filesystem-and-remount-the-clients route.</p>
<p>As for inode generation counts, though, <code>fsirand(1M)</code> (called by <code>newfs(1M)</code>) would suggest that the answer to your question is probably "no."</p>
</div>2006-09-12T21:43:36ZBy Chris Siebenmann on /blog/solaris/InplaceDefragmentationtag:CSpace:blog/solaris/InplaceDefragmentation:1e17b3e14257d76a9f4ca47bc362b8f90671677dChris Siebenmann<div class="wikitext"><p>If you make a new filesystem, does the root inode's generation count and
other stuff come out the same? (I suppose it pretty much has to have the
same generation count if it's a true generation count, since you can't
ever do any of the things to it that change the generation count.)</p>
</div>2006-09-12T20:56:07ZBy Dan.Astoorian on /blog/solaris/InplaceDefragmentationtag:CSpace:blog/solaris/InplaceDefragmentation:a62a8b26f60db3e2e48f7b89c1bc1f44580c3b64Dan.Astoorian<div class="wikitext"><blockquote><p>The procedure is slightly less nerve-wracking if you have a three way mirror, but should work OK even for a two-way mirror. Here's how it goes:</p>
<ol><li>bring the machine into single-user mode, but do not unmount the filesystem you want to defragment.</li>
<li>insure that all the submirrors are in sync.</li>
<li><code>metadetach</code> all but one submirror.</li>
<li><code>rm</code> everything in the filesystem except the <code>lost+found</code> directory.</li>
<li><code>ufsdump 0f - /dev/md/rdsk/<detached submirror> | ufsrestore rf -</code></li>
</ol>
<p>[...]</p>
</blockquote>
<p>Fiddling with detached submirrors like this always made me slightly nervous (perhaps groundlessly). Personally, I've always preferred this approach:</p>
<ol><li><code>metadetach</code> one submirror</li>
<li><code>metainit</code> a <em>new</em> mirror using the old submirror's device, and mount and clear the filesystem</li>
<li><code>ufsdump 0f - /dev/md/rdsk/<original mirror> | ufsrestore rf -</code></li>
<li>verify that the copy was correct and complete</li>
<li>unshare and unmount the filesystems, and use <code>metarename -x</code> to exchange the mirrors' metadevice numbers</li>
<li>remount and reshare the defragged filesystem (using its original metadevice number)</li>
<li>tear down the old, now-unused mirror, and attach its submirror(s) to the new mirror.</li>
</ol>
<p>If the filesystem is large, you can even try to minimize your downtime by doing the level-0 dump while the system is live to copy most of the data, then taking the data set offline and doing an incremental dump to pick up the changes that occurred during the level-0.</p>
<p>The difference between your approach and mine is that my way, you never have to access a submirror directly: all accesses are through a bona fide mirror metadevice. Note that the NFS filesystem handles are tied to the metadevice <em>numbers</em> of the mirrors: NFS will not notice that you've exported a different mirror with the same number.</p>
<p>In fact, I've used this method to convert a simple metadevice into a one-way mirror (as a prelude to growing the filesystem onto a larger physical device) without the NFS clients missing a beat:</p>
<ol><li><code>ifconfig</code> down the server's network interface, so the NFS clients won't get failures for the filesystem while it's unavailable;</li>
<li>from the console or via a second network interface, unshare and unmount the filesystem</li>
<li><code>metarename</code> the device, and <code>metainit</code> a mirror using the original device as a submirror (e.g., <code>metarename d1 d11; metainit d1 -m d11</code>)</li>
<li>remount and reshare the filesystem, and <code>ifconfig</code> the network back up.</li>
</ol>
<p>--Dan Astoorian</p>
</div>2006-09-12T18:01:56Z