Date: Sat, 2 Mar 2002 18:40:00 -0600 From: "Mike Meyer" <mwm-dated-1015548002.d8e942@mired.org> To: "David Smithson" <david@customfilmeffects.com>, "C J Michaels" <cjm2@earthling.net> Cc: questions@freebsd.org Subject: Re: defragment UFS Message-ID: <15489.28896.233718.110168@guru.mired.org> In-Reply-To: <21906063@toto.iv>
next in thread | previous in thread | raw e-mail | index | archive | help
David Smithson <david@customfilmeffects.com> types: > This is a multi-part message in MIME format. > > ------=_NextPart_000_0020_01C1C163.AB51EA80 > Content-Type: text/plain; > charset="iso-8859-1" > Content-Transfer-Encoding: quoted-printable Ugh. Could you please set your mailer to send only text, not text+html? The digester on the freebsd mail system eats mime headers, and I've been unable to get anyone to fix that. > Hi all. Is there a defragment utility for FreeBSD? Is it even = > necessary? If not, why not? No, there isn't. It's usually not necessary. Why not is a longer answer. Basically, FFS has two different block sizes, the real one, and the "fragment" size. More on that in a bit. A file consists of however many blocks (typically 8K) it needs, then a fragment (typically 1K) that holds the last little bit. When the file grows, it has to read the block in before it can write it back out, so if it grows into the next fragment, it'll just write the block to a free block, and add the fragment that it used to use to the free fragment list. Now do a "df /", and then take the size in 1K-blocks and multiply by the capacity. For example: guru% df / Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/da0a 162687 71166 78507 48% / gives 162687 * .48 = 78089.76. That's not the number of blocks used. The reason it doesn't add up is because the 1K-blocks is full size of the file system, but the available and capacity numbers are figured based on how the file system reserving a percentage of the block as free space so it can optimize the file system for speed. You can control that number when you make the file system - maybe even afterwards, I'm not sure - but if the total free space shrinks below a certain value, the file system switches to optimizing for space instead of speed. C J Michaels <cjm2@earthling.net> types: > > -----Original Message----- > > From: owner-freebsd-questions@FreeBSD.ORG > > [mailto:owner-freebsd-questions@FreeBSD.ORG]On Behalf Of David Smithson > > Sent: Saturday, March 02, 2002 2:08 AM > > Cc: freebsd-questions@FreeBSD.ORG > > Subject: Re: defragment UFS > > I see. Well that's dandy. I have another filesystem-related question. > > I have a 1.2TB file server running FreeBSD. The filesystem is exported > > via SMB. When I view the properties of a SAMBA shared folder, there are > > two file sizes shown: "size" and "size on disk". The "size on disk" is > > consitently greater than the "size". I ignorantly assumed this meant > > that data was fragmented. Do you have any idea what this means? > When Windows is reporting size vs size on disk, it's reporting the > difference between the actual size of the files and the amount of space > allocated to the file. There's a minimum amount of space that can be > allocated on a FAT filesystem (which depends on several factors). E.g. if > the cluster size is 32KB, and you save a file that's only 8KB, it still > takes up 32KB "on disk". This is generally called "slack" space. > > Couple this with the high fragmentation rate of FAT/NTFS filesystems and you > end up with alot of space being allocated to files that isn't actually used. > > What you are seeing in the properties box when viewing a SAMBA share is pure > fiction. Your 2k box believes it is looking at an NTFS filesystem (not ufs) > so it also assumes the same cluster size, and the same issues with slack > space. > > Long story short, the actual size should be accurate, and the "size on disk" > is fiction, just ignore it. Actually, they're both just fiction. FreeBSD has a similer size that things round up to. But it's typically 1K, and that would be the *real* "size on disk" of the file. I have no idea how samba deals with the strange methods that DOS has for dealing with files that fill a partial block, and only a slightly better idea of how DOS clusters behave, so I'm not positive that the amount of disk space is the minimimum for FreeBSD. I'm also not sure if SAMBA takes advantage Unix's ability to have holes with files in them, either. This is how you get a file a terabyte long on a 1.44M floppy. I wonder what samba would do with it? <mike -- Mike Meyer <mwm@mired.org> http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?15489.28896.233718.110168>