On 10/24/2010 03:46 AM, Patrick Dupre wrote: > On Sat, 23 Oct 2010, JD wrote: > >> On 10/23/2010 02:49 PM, Patrick Dupre wrote: >>> On Sat, 23 Oct 2010, Patrick Dupre wrote: >>> >>>> Hello, >>>> >>>> On a logical partition I am unable to set the block size to 1024 ! >>>> I formatted the partition mke2fs /dev/VG1/part1 -b 1024 -t ext4 >>>> and when I do a >>>> blockbsz --getbsz or mke2fs -n >>>> I get 4096 ! >>>> I also tried 2048 with the same result. >>> But dumpe2fs gives the right answer ! >>> >>>> >>>> Is it related to the logical partition ? >>>> >>>> Thank. >>>> >>>> >>> >> You have to be aware that selecting such a small >> block size means that the FS will be allocating >> at least 256 bytes of inode space per 1K data block. >> So, the amount of space for on-disk metadata is about >> 25% of the space for data blocks. This is OK if you have >> a lot of small files about 1 to 4k in size. Buf it most of >> your files are much larger than 1kb, then you have >> wasted a lot of disk space for inodes that may never >> be used. > Is there a tool to optimize the block size ? > Determination of the average file size ? > > Thank. > A middle of the road selection of the block size, and proper selection of the fragment size would probably serve you well if your file sizes are evenly distributed within your existing range from smallest file to largest file. So, you might want to run mkfs and select a block size of say,.. 4k or 8k, and a fragment size of 1k. fragment size has a tiny computational overhead when creating a new file, or expanding a current file. This will support both large files and small files. The caveat is that the probability that the last block of a file has unused fragments is 50%. Which is not bad at all - since we are talking only about the very last block occupied by a file. Also, fragments eventually end up being used anyhow during file expansions and new file creations. This scheme has a slight performance overhead, but makes maximal use of the disk space. So, if you are not into super high performance requirements, such as realtime acquisition and storage of large data from multiple sources, then I believe this would be a good choice. -- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
