Like a lot of block-level logical storage managers, LVM has a basic read-only snapshot facility. A remapping storage manager makes it easy to implement snapshots, since basically all you do is remap blocks on write (although the devil is in the details, as always). And like most of them with snapshot facilities, I believe that LVM lacks hooks into filesystems to tell them about an impending snapshot.

You might reasonably ask why the filesystem should care about this. The simple answer is that you really want the filesystems in your snapshots to be marked as clean and consistent, so that when you go to mount them, nothing freaks out about dealing with a dirty filesystem. These days, a lot of filesystems want to do various sorts of recovery actions when you try to mount a dirty filesystem; for example, when ext3 mounts a dirty filesystem, it tries to replay the log of pending transactions to bring the filesystem up to consistency. At least some of these recovery actions (such as ext3's) don't go together very well with a genuinely read-only filesystem.

(I believe that ext3 has sensible reasons for wanting to replay the log even when you mount a filesystem read-only, since if it did not replay the log to the disk it would have to build an in-memory version of the log's changes. Not having two recovery paths has to be more reliable, especially when the in-memory one is only going to be exercised infrequently.)

Making sure that the snapshot is clean and consistent also makes them more useful for block-level backup tools like dump. An unchanging filesystem makes it more likely that dump will work, but I have seen frozen filesystems that were still in a peculiar enough state that dump failed. And speaking as a sysadmin, I am really in favour of reliable dump.