There is no "right" answer to such a limited question. If your setting up a desktop or laptop, just do:
mkfs.ext3 /dev/sda1
The program can choose way better than an inexperienced human being. If your going to store a huge website, ext3 might require up to 25% inodes, because of the massive possible number of small individual files.
But you're really only telling the mkfs
program "up to 25% inodes." Most file system creation settings are used in specialized applications, such as RAID striping, where the geometry of the file system has to be tuned or it will be incredibly slow.
I know people have their pet file system settings. I have yet to find anyone who can demonstrate the usefulness of departing from default values on a 40 GB desktop or laptop partition.
And ext3 is not the best file system for everything! I use three different partition format types on my lappy, because certain partitions hold many small, individual files. Others hold a much smaller number of larger files (good for ext3 system), like /home partition.
/usr
can have 500,000 individual files, making ext3 klunky, but reiserfs flies. The other thing is acls. You must inform mkfs.ext3
that you'll be using acls, if you'll be using them. acls are fine tuning for permissions, usually not important on a single user system. But if you have a group of 20 normal users, and you want differing access controls for some of them, you must use acls.
I personally like xfs for a general use filesystem, although it doesn't work out of the box with SELinux. But it's the most sophisticated and efficient file system. It's used on several brands of HPCs. You can google it if you so please. ext3 uselessly wastes 8% of the partition. That's outrageous.
But ext4 is better. I'm not going to spit out a command line for you. You must determine the use of the partition, and design the file system accordingly. ext3 is reliable, but so is a tank. That doesn't mean you want to drive one around town.
I hope this helps a little.
64k seems to be a good pick:
Results:
no bs= 78s 144584+0 records
bs=512 78s 144584+0 records
bs=1k 38s 72292+0 records
bs=2k 38s 36146+0 records
bs=4k 38s 18073+0 records
bs=5k 39s 14458+1 records
bs=50k 38s 1445+1 records
bs=500k 39s 144+1 records
bs=512k 39s 144+1 records
bs=1M 39s 72+1 records
bs=5M 39s 14+1 records
bs=10M 39s 7+1 records
(taken from here).
this matches with my own findings regarding read/write buffering for speeding up an io-heavy converter-program i was once pimping @work.
Best Answer
The lsblk command is great for this:
The results: