Date: Sun, 3 Mar 2002 08:56:15 -0500 From: "C J Michaels" <cjm2@earthling.net> To: "Paul Mather" <paul@gromit.dlib.vt.edu> Cc: <questions@freebsd.org> Subject: RE: defragment UFS Message-ID: <CDEJIONOMGKHCNHBALKPAEKKCAAA.cjm2@earthling.net> In-Reply-To: <20020302194234.C82401-100000@mule.Chelsea-Ct.Org>
next in thread | previous in thread | raw e-mail | index | archive | help
> From: Paul Mather > Sent: Saturday, March 02, 2002 8:00 PM > Subject: Re: defragment UFS > > > => 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. I didn't mean to imply the concept of slack space/fragmentation was fiction. What I'm saying is that the numbers being reported by windows was fiction. I'm not sure whether Windows or Samba is at fault, but the "size on disk" calculations are way off the mark. I guess I should have clarified that. For example: My home directory on my FBSD box is approx 1.9GB in size (per du). Now if I go and pull up the properties of said directory in Windows (through samba) it shows the size to be ~1.9GB but the size on disk to be 36.6GB!?! (which is physically impossible) Either way you give a good description of file fragments on FFS, thanks. :) > > 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?CDEJIONOMGKHCNHBALKPAEKKCAAA.cjm2>