Date: Sat, 3 Mar 2007 15:01:12 +0100 (CET) From: Christian Baer <christian.baer@uni-dortmund.de> To: freebsd-questions@freebsd.org Subject: Re: defrag Message-ID: <esbv38$30u3$6@nermal.rz1.convenimus.net> References: <539c60b90703010849x33dd4bbbt8f6ca6aa0c8e83a0@mail.gmail.com> <20070301192109.A24369@chylonia.3miasto.net> <20070302085100.125cf488@localhost> <20070301221738.GA86154@gizmo.acns.msu.edu> <es7tvd$b33$1@sea.gmane.org> <20070302161225.GB90036@gizmo.acns.msu.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 2 Mar 2007 11:12:25 -0500 Jerry McAllister wrote: > On the other hand, doing all this either way wouldn't make any difference > in performance for file access in a running system because so-called > fragmentation is not an issue in the UNIX file system - except in > the small possibility that it might make a bit of difference in a > file system filled to capacity, well in to the reserve where non-root > processes are not allowed to write anyway. I don't know just how > close to absolutely full you have to get to see any difference, but it > is beyond what users would normally get to. You do know that you can use 'tunefs -m 0'? This will in fact cause fragmentation to happen - even on UFS2! UFS2 has methods of avoiding fragmentation that work quite well but it is not a 'magical' file system, which only means that every gain comes with a price. In this case the price is 10-15% of the HD's space. BTW. I have used tunefs to utilize all of my space on some drives. However, these drive contain only static information that has to be accessed often and then fast. That is the reason why it is on a drive at all. If you know what you are doing then this option is ok. Otherwise, the use will run into trouble when the drive fills up and the information stored on it is not static. Regards Chris
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?esbv38$30u3$6>