On a fairly frequent basis I've been getting diagnostic messages by the hundreds in batches (via Console), such as the following:

14-09-17 8:01:53.000 kernel: add_fsevent: unable to get path for vp 0xffffff8012f7de08 (ImapMail; ret 22; type 2)
14-09-17 8:01:53.000 kernel: add_fsevent: unabled to get a path for vp 0xffffff8012f7de08. dropping the event.

14-09-18 9:38:46.000 kernel: add_fsevent: unable to get path for vp 0xffffff80125a2f80 (crls; ret 22; type 2)
14-09-18 9:38:46.000 kernel: add_fsevent: unabled to get a path for vp 0xffffff80125a2f80. dropping the event.

I have no idea what they refer to and whether they represent something I should be concerned about and, if so, how to fix the issue.

Anybody have a clue?

iMac (mid-2011, 2.5 GHz Intel Core i5), Mac OS X Lion (10.7.5)

Nobody know nothin'?!
That's even stranger than the query.

I suspect you are going to have to talk to a software developer to get the answer. It could be a malformed call to an API or even an out of date API. From the couplets you provided we cannot even tell what application or kext is involved. All we know is that it is occurring in the kernel.

Thanks for the input. Unless there's a software developer lurking in the FTM wings, that's not likely going to happen.
Since this has been going on for years and doesn't seem to be causing any noticeable problems (other than 'clogging up' the diagnostic messages in Console), I'm just going to accept it as benign albeit annoying and move on.

Not just any developer it would have to be a developer working on the offending software. Try grabbing a half dozen or so log file lines before and after the offending message and maybe we could at least identify the offending app or kext.

By-the-way, I just scanned my log file (this is in Yosemite) for fsevents and the only entries I found were warnings for applications using API calls that have been deprecated and those all specified the API the call should be migrated to. So I am confident you have an app or kext with a malformed API call. You may just have an out-of-date app or kernel extension.

It would seem that it has to do with Time Machine backup.
All those messages appear (but not every time) sandwiched between the following:

14-09-21 12:37:51.646 com.apple.backupd: Starting standard backup
14-09-21 12:37:52.142 com.apple.backupd: Backing up to: /Volumes/XYZ Backup/Backups.backupdb

14-09-21 12:38:38.068 com.apple.backupd: Backup completed successfully.

So even though there are all those "dropped events", the backup seems to have been successfully accomplished.

Sounds reasonable, but could you send the entire thread (if there are too many repetitions delete the ones in the middle and annotate with <snip>)

Here's one of the smaller sets, from beginning to end of backup:

14-09-21 9:03:37.611 com.apple.backupd: Backing up to: /Volumes/XYZ Backup/Backups.backupdb
14-09-21 9:03:52.073 com.apple.backupd: 2.77 GB required (including padding), 802.28 GB available
14-09-21 9:04:04.000 kernel: add_fsevent: unable to get path for vp 0xffffff801556da28 (ujb90daz.default; ret 22; type 2)
14-09-21 9:04:04.000 kernel: add_fsevent: unabled to get a path for vp 0xffffff801556da28. dropping the event.
14-09-21 9:04:05.000 kernel: add_fsevent: unable to get path for vp 0xffffff801556da28 (ujb90daz.default; ret 22; type 2)
14-09-21 9:04:05.000 kernel: add_fsevent: unabled to get a path for vp 0xffffff801556da28. dropping the event.
14-09-21 9:04:05.000 kernel: add_fsevent: unable to get path for vp 0xffffff801556da28 (ujb90daz.default; ret 22; type 2)
14-09-21 9:04:05.000 kernel: add_fsevent: unabled to get a path for vp 0xffffff801556da28. dropping the event.

< snip – 14 items = 7 identical pairs omitted >

14-09-21 9:04:06.000 kernel: add_fsevent: unable to get path for vp 0xffffff801556da28 (ujb90daz.default; ret 22; type 2)
14-09-21 9:04:06.000 kernel: add_fsevent: unabled to get a path for vp 0xffffff801556da28. dropping the event.
14-09-21 9:04:06.000 kernel: add_fsevent: unable to get path for vp 0xffffff801556da28 (ujb90daz.default; ret 22; type 2)
14-09-21 9:04:06.000 kernel: add_fsevent: unabled to get a path for vp 0xffffff801556da28. dropping the event.
14-09-21 9:04:06.000 kernel: add_fsevent: unable to get path for vp 0xffffff801556da28 (ujb90daz.default; ret 22; type 2)
14-09-21 9:04:06.000 kernel: add_fsevent: unabled to get a path for vp 0xffffff801556da28. dropping the event.
14-09-21 9:04:08.454 com.apple.backupd: Copied 1231 files (12.4 MB) from volume XYZ.
14-09-21 9:04:08.634 com.apple.backupd: 2.76 GB required (including padding), 802.26 GB available
14-09-21 9:04:12.166 com.apple.backupd: Copied 578 files (717 KB) from volume XYZ.
14-09-21 9:04:13.602 mds: (Error) Volume: Could not find requested backup type:2 for volume
14-09-21 9:04:13.604 com.apple.backupd: Starting post-backup thinning
14-09-21 9:04:13.604 com.apple.backupd: No post-back up thinning needed: no expired backups exist
14-09-21 9:04:13.988 com.apple.backupd: Backup completed successfully.

I can't tell you exactly what is going on, but now there is enough information to go on to draw reasonable conclusions…

• Originally Posted By: your log file

  14-09-21 9:04:13.988 com.apple.backupd: Backup completed successfully.
  The backup is completing successfully so you still have a good Time Machine backup.
• Originally Posted By: your log file

  14-09-21 9:04:04.000 kernel: add_fsevent: unable to get path for vp 0xffffff801556da28 (ujb90daz.default; ret 22; type 2)
  14-09-21 9:04:04.000 kernel: add_fsevent: unabled to get a path for vp 0xffffff801556da28. dropping the event.
  There is a glitch in your volume directory with an entry or entries with either non-existent or invalid file paths. backupd is making several attempts to resolve the issue(s) and then giving up and continues backing up the rest of the files.

If I were in your shoes I would run a version of DiskWarrior, TechTool Pro, Drive Genius, or even as a last resort Disk Utility apropos to your version of OS X to repair or rebuild your volume directory. If errors are found (and hopefully repaired), and if I had TechTool Pro or Drive Genius I would then invest the time to run a full surface scan of the hard drive. The surface scan is probably unnecessary, but given its proven efficacy in anticipating future drive failures (far superior to S.M.A.R.T.) it would make me feel more confident in my drive's health.

Once again, many thanks for your taking the time and trouble to assess the situation.

I ran Verify Disk under Disk Utility's First Aid with the following results:

Verifying volume “XYZ”
Checking file system
Performing live verification.
Checking Journaled HFS Plus volume.
Checking extents overflow file.
Checking catalog file.
Checking multi-linked files.
Checking catalog hierarchy.
Checking extended attributes file.
Checking volume bitmap.
Checking volume information.
The volume XYZ appears to be OK.

Under the circumstances (ie, no apparent issues requiring repair) I saw no point to running off Recovery HD in order to use the Repair Disk function to repair or rebuild the volume directory (and I don't even know if such is an option there, but I haven't looked).

As for performing a surface scan, I don't have a clue where I'd even start, and Pogue's Missing Manual doesn't even mention such.

Since my hard drive was replaced less than a year ago and since nothing truly wonky is happening, I think that I may take the 'wait and see' approach.

Time for a nice glass of Grenache/Shiraz/Mourvèdre, while I flip my latest batch from the primary to the secondary.

If (as it appears) add_fsevent is running into a problem during a TM backup, the problem must be on the backup volume. TM wouldn't be adding a FileSystem Event to the volume it's backing up. It is creating files/folders on the backup volume, and each such creation would be an FSEvent.

Try verifying the backup disk. Be prepared to wait a while. You should probably temporarily disable automatic TM backups while doing the verify.

Thanks for another place to look.
A while is right: it took about 2 hours to run Verify and Repair the backup disk. Disk Utility found nothing to repair.
Quo vādīmus?

Add this to that:
Since running Disk Utility's First Aid (Verify on hard drive, Verify and Repair on the backup drive), even though nothing requiring repair was found, no more items of the ilk "kernel: add_fsevent ..." have shown up during TM backups. But only time will tell.
The only item which consistently continues to show up in the process is
14-09-21 9:04:13.602 mds: (Error) Volume: Could not find requested backup type:2 for volume .

ADDENDUM: Well, I was wrong: They're baaack. Another whack of "kernel: add_fsevent ..." items during the last backup.

Screw it! They're not interfering with operability, so I'm not going to pursue the issue (unless and until they do). Likewise for the mds error item noted above (which never disappeared).

Merci to all who contributed to the debate/effort.

I know this is not the case you are having but I did once have a weird error where the file count could not be resolved to the disk directory, resulting in a "Lost + Found" folder mysteriously appearing on the root level of the disk and every time I ran Disk Utility an entry to the folder was added. The SMS on the drive was incompatible with the SMS built into the computer resulting in an inconsistent count because the drive head would lock twice on movement. Maybe some kind of inconsistency in your case between the TM drive directory and the internal drive directory, a shot in the dark here.

SMS?

Maybe I'm having a senior moment (and will slap myself in the forehead immediately after posting this message), but I can't think of what SMS might stand for if not Short Message Service (the way text messages are sent on a cellular network), and that has nothing whatsoever to do with drives or filesystems or Lost + Found.

I also cannot fathom what you mean by "an inconsistency between the TM drive directory and the internal drive directory". Do you mean the file catalogs on the respective disk volumes? They need to be internally consistent, but don't need to be consistent with each other.

On an HFS+ volume, each folder has a link back to its parent. If, while checking the disk catalog, a folder is found whose parent does not exist, a "Lost + Found" folder will be created if necessary, and the orphan folder will have its parent set to that. Similarly for a file whose parent folder does not exist. These are both, of course, situations that should never happen. Disk Repair is paying homage to Murphy's Meta-law: Even things that cannot go wrong, will go wrong.

Sudden Motion Sensor. The Seagate drives that originally shipped with 2010 Macs, I think they were the Momentus, were eventually found to be incompatible and resulted in Lost + Found folders. I had never seen that error before. The computer and the drive had duplicate but out of sync actions when locking the drive head if the computer was moved quickly while running. This error was not explained to me completely but I was told it was an error in the directory matching the contents of the drive. People tell me things, it's not my fault if they aren't true! There was no more Lost + Found folder once I swapped out the internal drive for a WD and used the Seagate as an external. Seagate had it posted later on their website that this particular drive was incompatible for that reason.

As you ought to know by now, I am a TM noob and always will be. I thought perhaps there was some type of check-sum between the internal drive and TM. You know, to keep things from going wrong...

Thanks. Having never owned a portable computer, I keep forgetting all their niceties.

Still, Journaling should be adequate defense against sudden drive disconnects, and Time Machine will flat out refuse to back up to a disk volume that is not journaled. Methinks there is something else going on.

Although...

It could be a poorly designed drive. The way journaling works is, before making any change to the disk catalog, it first writes to the journal a description of what it's going to do. Then it asks the drive for confirmation that the intent has been physically written to the disk. Only then does it begin the change. That way, the data on the disk is (or can be made) valid no matter when a disconnect should happen. If it disconnects before the journal entry is written, the action never gets performed, and the disk catalog is still as consistent as it ever was. If it disconnects during the change, when the OS remounts the disk volume, it notices the entry in the journal, and completes any partial change, bringing the catalog back to a consistent state. If it disconnects after the change, the catalog is again consistent.

But there's a potential failure point. If, when the OS asks the drive "Are you sure this journal entry has been written to disk", a poorly designed drive may think to itself "Well, it hasn't, but it's in my cache and I plan to write it. Even if I lose power, I have enough energy stored in the spinning platter to finish the write, so for all practical purposes, it's written." Based on that (faulty) reasoning, the firmware on the drive responds "Yeah, yeah. I got it. Consider it written."

The drive has lied. It's a lie that won't be found out if the drive merely loses power, and that's why they think they can get away with it, but it's a lie. For journaling to work the way it's supposed to, the drive must not say something has been written until it truly has been written. (Even if it's just a power failure, the drive is gambling that it has enough stored energy to not only write what's in the cache but also do any necessary error recovery in the case of write errors. Seems like pretty flakey logic to me.)

So, OK, I see what seems to be happening. And you're right. The cure is to replace the drive by one with honest (aka non-buggy) firmware.

Got it. Thanks.