The merits of a partitionless filesystem

Pro: you don't waste one disk sector on a partition table. (Yay.)

Pro: the disk can be used in an operating system that doesn't support PC-style partitions. (Like you're going to use one.)

Con: this is unusual and may confuse co-sysadmins. (See?)

Con: if you install another operating system, it might think that the disk contains garbage and make it easy to accidentally overwrite it by selecting the wrong disk — whereas operating systems generally leave alone partitions whose type they don't understand.

Irrelevant: extending the filesystem is not easier if it's directly on the disk than if it's in a partition, nor vice versa. (Being on LVM would make it easier.)

Conclusion: it works, but it's not a good idea.

I see the real benefit when this is done in a virtual environment. Since our VMDK's are stored on our NAS, we can grow them dynamically.

If we're using partitions, either we need to use LVM (and the overhead associated with it) and chain the partitions together, or we need to take down the host (or filesystem if not in use) to use something like gparted.

However, if you use the whole disk instead of a partition, you can force a rescan on your SCSI disks and use resize2fs to grow the filesystem while it's online (and in use!).

Not sure about how this would apply to Linux but with native ZFS, one reason it is recommended to create pools on whole disks and not partitions is in the former case the disk write cache can be enabled.

Several other reasons also mentioned here:

http://www.solarisinternals.com/wiki/index.php/ZFS_Best_Practices_Guide#Storage_Pools

Conclusion: it works, and might be a good idea depending on the filesystem.