Date: Tue, 1 Jun 2004 16:23:20 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Vulpes Velox <kitbsdlist2@HotPOP.com> Cc: freebsd-fs@FreeBSD.org Subject: Re: file space question Message-ID: <20040601160031.T18025@gamplex.bde.org> In-Reply-To: <20040531213127.1eb7224c@vixen42.24-119-122-191.cpe.cableone.net> References: <20040531213127.1eb7224c@vixen42.24-119-122-191.cpe.cableone.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 31 May 2004, Vulpes Velox wrote: > Does ufs have the same problem like FAT32, in that if a file exists, > it will all ways take up atleast 4KB or so, no matter how little data > it contains? Not exactly. ufs has fragments, which normally have size 1/8 of the block size, so a 1 byte file normally only takes 1/8 of the block size. However, the default block size is 16K, so fragments usually take up at least 2K. If nonstandard block and fragment sizes are used, then the minimum is the same for ufs and msdosfs: ufs: block size 4096, frag size 512 msdosfs: block size 512 With FAT32, 512-byte blocks can cover fairly large disks. IIRC, there can be 2^28 clusters for FAT32, so the maximum is 2^28*512 = 128GB. The default block size for msdosfs originally grew large (up to 32K or 64K) back when there was only FAT16 and the limit was 2^16 or 2^15 clusters. 2*16*32K is just 2GB, so even with the too-large block size of 32K wasn't large enough for new disks about 10 years ago. Since then, 4K has become the default for most cases since it is a good i/o size (still a little too small, but OK with some buffering), and because using a reasonably large block size helps stops the FAT size from beoming preposterously large (2^28 clusters takes 1GB for the FAT). Also, msdosfs has much smaller metadata overheads than ufs, so it can hold a lot of small files in the space that ufs would use for metadata. The wastage is very noticable on small file systems like ones that fit on floppy disks. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040601160031.T18025>