Stephen's answer is a very good one, but anytime we start talking about 'data at rest' encryption, the question that should come to mind is 'what threats are we trying to protect the data against?'
Typically, an encrypted filesystem alone can protect you from some threats, not all of them. If the threat is a hard drive being physically removed from a server and 'walking out the door', and encrypted filesystem is an excellent protection. If the threat is a rogue sysadmin, it may not be sufficient.
An encrypted filesystem will be transparent to processes that read/write it through the operating system calls such as read() and write(). In order for splunk to work, it has to be transparent to the user running splunkd (or to the splunkd process itself). It's also possible for the operating system superuser (depending on the operating system in some cases) to read/write files on this encrypted filesystem.
On linux, a relatively common approach is to use dm-crypt + LUKS to encrypt the underlying block device. (I do this on my laptop) This is actually 'below' the filesystem - the filesystem is stored onto an encrypted block device. There is a performance penalty here, which may be unacceptable for a Splunk indexer -- as every read and write has additional CPU cycles attached to it for the encrypt/decrypt. And in certain kernel releases, the encrypt/decrypt activity is limited to a single CPU. (Newer kernels and a CPU with AES-NI instructions could help a LOT here)
There are some hardware solutions, such as hard drives that encrypt in firmware or "bump in the wire" fibre channel / iSCSI solutions (NetApp / formerly Decru has one of these) but they can be very expensive depending on your requirements.
Unfortunately, encryption for the sake of compliance is usually epically vague in what threats are being protected against (eg, 'all threats') and what is a suitable technology decision to make in order to meet the requirement.
