I think you're confused, possibly because you've read several documents that use different terminology. Terms like “block size” and “cluster size” don't have a universal meaning, even within the context of filesystem literature.
Filesystems
For ext2 or ext3, the situation is relatively simple: each file occupies a certain number of blocks. All blocks on a given filesystem have the same size, usually one of 1024, 2048 or 4096 bytes. A file¹ whose size is between N blocks plus one byte and N+1 blocks occupies N+1 blocks. That block size is what you specify with mke2fs -b. There is no separate notion of clusters.
The FAT filesystem used in particular by MS-DOS and early versions of Windows has a similarly simple space allocation. What ext2 calls blocks, FAT calls clusters; the concept is the same.
Some filesystems have a more sophisticated allocation scheme: they have fixed-size blocks, but can use the same block to store the last few bytes of more than one file. This is known as block suballocation; Reiserfs and Btrfs do it, but not ext3 or even ext4.
Utilities
Unix utilities often use the word “block” to mean an arbitrarily-sized unit, typically 512 bytes or 1kB. This usage is unrelated to any particular filesystem or disk hardware. Historically, the 512B block did come about because disks and filesystems at the time often operated in 512B chunks, but the modern usage is just arbitrary. Traditional unix utilities and interfaces still use 512B blocks sometimes, though 1kB blocks are now often preferred. You need to check the documentation of each utility to know what size of block it's using (some have a switch, e.g. du -B or df -B on Linux).
In the GNU/Linux stat utility, the blocks figure is the number of 512B blocks used by the file. The IO Block figure is the preferred size for file input-output, which is in principle unrelated but usually an indication of the underlying filesystem's block size (or cluster size if that's what you want to call it). Here, you have a 13-byte file, which is occupying one block on the ext3 filesystem with a block size of 2048; therefore the file occupies 4 512-byte units (called “blocks” by stat).
Disks
Most disks present an interface that shows the disk as a bunch of sectors. The disk can only write or read a whole sector, not individual bits or bytes. Most hard disks have 512-byte sectors, though 4kB-sector disks started appearing a couple of years ago.
The disk sector size is not directly related to the filesystem block size, but having a block be a whole number of sectors is better for performance.
¹
Exception: sparse files save space .
Many disks have a sector size of 512 bytes, meaning that any read or write on the disk transfers a whole 512-byte sector at a time. It is quite natural to design filesystems where a sector is not split between files (that would complicate the design and hurt performance); therefore filesystems tend to use 512-byte chunks for files. Hence traditional utilities such as ls and du indicate sizes in units of 512-byte chunks.
For humans, 512-byte units are not very meaningful. 1kB is the same order of magnitude and a lot more meaningful. A filesystem block (the smallest unit that a file is divided in) actually often consists of several sectors: 1kB, 2kB and 4kB are common filesystem block sizes; so the 512-byte unit is not strongly justified by the filesystem design, and there is no good reason other than tradition to use a 512-byte unit outside a disk driver at all.
So you have a tradition that doesn't have a lot going for it, and a more readable convention that's taking on. A bit like octal and hexadecimal: there isn't one that's right and one that's wrong, they're different ways of writing the same numbers.
Many tools have an option to select display units: ls --block-size=512 for GNU ls, setting POSIXLY_CORRECT=1 in the environment for GNU df and GNU du to get 512-byte units (or passing -k to force 1kB units). What the stat command in GNU coreutils exposes as the “block size” (the %B value) is an OS-dependant value of an internal interface; depending on the OS, it may or may not be related to a size used by the filesystem or disk code (it usually isn't — see Difference between block size and cluster size). On Linux, the value is 512, regardless of what any underlying driver is doing. The value of %B never matters, it's just a quirk that it exists at all.
Best Answer
No. The disc block size says, in how big byte chunks is the data handled on the disk. If you write something to a file, your CPU/motherboard has to say to the drive controller, what bytes should be written in which sector of the disc. This can happen only in 512byte chunks.
The distinction between the logical and physical sector size is this: the physical sector size is in which the data is organized in the disc physically. The logical sector size means the chunks with your CPU/motherboard can talk with your driver controller card (which is often also a part of your motherboard, but your OS still has to know, what block sizes should it produce as it executes a disc read/write operation).
Since some decades, also the physical sector size is a faked one, and the exact details of it is a business secret of the hard disc manufacturer. But the OSes still have to know this faked data, because it is part of the disc standards (SCSI, PATA, SATA, etc). Thus the physical sector size has no practical meaning in most cases.
On some newer discs there is a new development, that they use 4096-logical sectors instead 512. It is needed because the sector numbers on some old ATA protocols have a 32 bit size, thus discs larger as 4billion sectors (=2Terabytes) couldn't be addressed on them.
The stat command says the block size of your filesystem. Also most filesystems organize data in blocks on your system. If you create a single byte file, it will have to allocate 4096 bytes on your disc. There is only rarely a non-block oriented filesystems, for example Reiserfs, although it is still organized in blocks, its smallest allocatable disc size is only 32 bytes. Thus an 1 byte file will allocate only 32 byte on a reiserfs filesystem.