What is the buffers column in the output from free?
free pulls its data from /proc/meminfo
slkwr133701:/usr/src/linux # free
total used free shared buffers cached
Mem: 2053456 434572 1618884 0 77888 201820
slkwr133701:/usr/src/linux # cat /proc/meminfo
MemTotal: 2053456 kB
MemFree: 1618736 kB
Buffers: 77928 kB
....
This refers to memory used for temporary block I/O storage. The kernel has to assign and free the same size units constantly like block I/O transfers, network packets, and socket buffers
You can get a better look at caches and buffer allocations by running slabtop
In response to your usage question: The system will typically allocate more blocks than it needs but as the "memory pressure" increases these additional blocks will be released.
"buffers" are reclaimable under memory pressure. So it is similar to the page cache ("cache" column); not a big cause for concern. The "buffers" value can be small or large, it depends what your system is doing :-). We can find several types of cache counted here.
The buffer cache is literally the page cache for the block device. Linux just reports these separately.[*] You could notice "buffers" usage while programs read/write the block device node, e.g. dd status=progress if=/dev/sda of=/dev/null. Apparently people also notice it when running a DVD player program.
For proof, see: 30% of RAM is "buffers". What is it?
If you have not been accessing the block device node, your "buffers" are probably all filesystem metadata. Filesystems use the buffer cache internally as a convenience. They make sure it never duplicates the file data - file contents - which is stored in the main page cache. Exactly what the filesystem uses the buffer cache for - if anything - varies depending on the filesystem.
On a machine with a small amount of physical RAM, I noticed "buffers" can look high, when I have ext3/ext4 filesystems. This was because writes to the journal go through the buffer cache. (See link above). ext3/4 filesystems also store directory contents in the buffer cache.
Secondly, "buffers" shown by the free command also include SReclaimable, meaning reclaimable slabs. (Demonstrated here: The Right Way to Monitor Linux Memory, Again).
Slab memory is not part of the page/buffer cache. However it is convenient to count them together. They are both reclaimable, and the main (only?) use of reclaimable slabs is for filesystem caching. For example file metadata (inodes) and path lookups (dentry's) are cached in reclaimable slabs. "Reclaimable slab memory [can] take up a large fraction of system memory on mostly idle systems with lots of files."
You can see the raw Buffers and SReclaimable values in cat /proc/meminfo. You can also run slabtop to see the list of slabs. AFAICT, slabtop doesn't give stats on slabs as reclaimable or not. But you can usually guess, and if there is some suspicious slab I guess you can look it up by name.
[*] For the purposes of this answer, "buffer cache" is the cache counted by Buffers in /proc/meminfo. However other sources may refer to the entire page cache as a unified buffer cache. If you want the historical explanation, see the first link.
Also Linux developers may have used "buffer cache" to mean different things, when they were squabbling about filesystem implementations.