To start off, you are using a very old version of the fs/tools. 2+ year old. Upgrading will take care of the -R option.
However, the basic problem you are experiencing will remain. As in, ocfs2 uses blocksized inodes. You can reduce the blocksize, but that will result in a loss of thruput as the ios are typically blocksized. The problem we face is that on one hand the disk sizes are exploding. Same with the media/datafiles. These all benefit from larger blocksizes. Infact there is move afoot in the kernel to allow >4K blocksizes. But increasing the blocksizes implicitly makes it more expensive (space-wise) to have lots of files. While the local file systems don't have block-sized inodes, they still make block-sized data allocations. Yes, some local filesystems like reiser are known for being very efficient in having a large number of small files, but often at the expense of the other extreme. In software, we typically encounter competing interests and are forced to make trade-offs. OCFS2 developers are aware that large number of small files is problematic in terms of space usage. We are addressing those concerns. For e.g., we have had inline data support added in 2.6.25. The tools support for the same is in progress. What this will do is push files <3.5K into the inode itself. That will make it more space efficient (wee-bit) than ext3/xfs. We have some more ideas that we are exploring on this front. Sunil Jerônimo Bezerra wrote: > Hello All again, > > no suggestions? No advices? I need some light! Please! > > Thanks again > > Jerônimo > > > Luis Freitas escreveu: > >> Funny, I could not find a option to specify the number of inodes or >> the inodes/bytes ratio on mkfs.ocfs2? >> >> Regards, >> Luis >> >> >> --- On *Tue, 7/22/08, [EMAIL PROTECTED] /<[EMAIL PROTECTED]>/* wrote: >> >> From: [EMAIL PROTECTED] <[EMAIL PROTECTED]> >> Subject: [Ocfs2-users] Recommended block size for a mail environment >> To: [email protected] >> Date: Tuesday, July 22, 2008, 9:22 AM >> >> Hello all, >> >> I have a mail environment, with a situation seemed with a previous >> mail "Different size with du and ls". My environment is: >> >> Debian Etch 4.0 >> Postfix 2.3.8-2 >> ocfs2-tools 1.2.1-1.3 >> kernel 2.6.18-4-amd64 >> >> My "df -h" shows me the follow: >> >> df -Th >> /dev/sdb1 ocfs2 1,0T 894G 131G 88% >> /mails >> >> df -Thi >> File Syst. Type Inodes IUsed IFree IUse% Mount on >> /dev/sdb1 ocfs2 16M 14M 2,1M 88% /mails >> >> but when I do a "du -sh . /mails" it shows me 480GB, so much >> different >> from 849G. The OCFS2 block size is 4K. I made a script to average the >> medium mail size, and it's the follow: >> >> 0k to 1k - 8% >> 0k to 2k - 13% >> 0k to 3k - 22% >> 0k to 4k - 35% >> 4.1k to 6k - 15% >> 6.1 to 8k - 10% >> 8.1k to 10k - 9% >> 10.1k to 12k - 7% >> rest - 24% >> >> My debug.ocfs2 doesn't has the "-R" option: >> >> # debugfs.ocfs2 -R "stats" /dev/sdb1 >> debugfs.ocfs2: invalid option -- R >> debugfs.ocfs2 1.2.1 >> >> >> My doubts are: >> >> 4k is a good block size for this situation? >> How to avoid waste space as now (~50%)? >> If I choose to use 2k, will the available Inodes double (16M to 32M)? >> >> Thanks a >> lot! >> >> Jeronimo >> >> ---------------------------------------------------------------- >> Universidade Federal da Bahia - http://www.portal.ufba.br >> >> >> >> _______________________________________________ >> Ocfs2-users mailing list >> [email protected] >> http://oss.oracle.com/mailman/listinfo/ocfs2-users >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Ocfs2-users mailing list >> [email protected] >> http://oss.oracle.com/mailman/listinfo/ocfs2-users >> > > > > _______________________________________________ > Ocfs2-users mailing list > [email protected] > http://oss.oracle.com/mailman/listinfo/ocfs2-users > _______________________________________________ Ocfs2-users mailing list [email protected] http://oss.oracle.com/mailman/listinfo/ocfs2-users
