Date: Sat, 2 Mar 2002 20:00:09 -0500 (EST) From: Paul Mather <paul@gromit.dlib.vt.edu> To: questions@FreeBSD.ORG Subject: Re: defragment UFS Message-ID: <20020302194234.C82401-100000@mule.Chelsea-Ct.Org> In-Reply-To: <bulk.5988.20020302155148@hub.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
=> Date: Sat, 2 Mar 2002 10:15:32 -0500
=> From: "C J Michaels" <cjm2@earthling.net>
=> Subject: RE: defragment UFS
=>
=> > -----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.
It's not really fiction. The smallest unit of disk space the end part
of a file can occupy in a FFS filesystem is a fragment. Usually this is
1/8th the block size, and in 4.5, the default block size is 16 KB and
default fragment size 2 KB. So, for example, the date of a 16385 byte
file in such a file system would actually take up an extra 2047 bytes
"on disk" compared to the reported file size.
AFAIK, each file must occupy at least one block. So, with the above
defaults, if you have lots of small files (< 1 block), you'll have an
average of 8 KB "wasted" data disk space per file. If the bulk of your
files are > 1 block in size, then on average you'd "waste" half a
fragment, or 1 KB for every file.
Anyway, that is why the "size on disk" will *always* be >= the "size"
for any given file.
Cheers,
Paul.
e-mail: paul@gromit.dlib.vt.edu
"Without music to decorate it, time is just a bunch of boring production
deadlines or dates by which bills must be paid."
--- Frank Vincent Zappa
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?20020302194234.C82401-100000>