nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

TFilePoint::ReadDataInternal warning in iwtrace log

brizrobbo

Hi Folks,

I've just been checking our iwtrace log file, and I notice that every now and again I get a warning like:

[Mon Jun 20 14:49:26 2011] TFilePoint::ReadDataInternal: invalid forwarded data 0xa69a21 for id 0xa9249c

After a thousand entries or so (over the course of about 2-3 seconds), it stops.

It doesn't have seem to affected any functionality at all.

Has anyone seen warnings like these before? And is it anything to be concerned about?

Cheers.

Find more posts tagged with

Comments

Rick Poulin

I don't know what that message means, but the hash keys look like data points in the content store. You may want to run a thorough iwfsck to make sure your content store is still healthy.

brizrobbo

Thanks. I have logged a job with IWOV support and they suspect much the same: a corrupt content store. They recommended an iwfsck.

Tim__D

I would be very interested on what you have discovered. We're on a similar platform and have the same issues. We have had this occur in conjunction with massive file modification and file corruption.

Any information you have on this would be appreciated.

Thanks,

Tim

brizrobbo

I ended up logging a job with support about this, and they asked me to do an iwfsck on that store (as you would expect).

I did this using this command:

/Interwoven/TeamSite/private/bin/iwfsck -d -a -r -t -b /iw-store/default /default/main

It came up with 17 errors. A typical error was like:

Error Begin. Shared data point 0xa6766d not found. Ref point 0xa8f268 (11072104)
    vpath(s) to file ID (11072104) is,
/reefprotection/images/snorkelling.jpg

Error End.

I then asked Support what I should exactly do (precisely) in order to rectify this. It must have been a hard question because it is now sitting with 'engineering' and they haven't yet got back to me. ;-)

I am tempted to just re-import those offending files and re-run the iwfsck to see if those errors go-away. However, I want to get to the bottom of what is going on, so that's why I haven't done anything about it yet.

I encourage you to log that issue with support as it might add to the knowledge. In the meantime, I will feedback any updates.

Tim__D

I still have a case open with IWOV. They are now suggesting performing an iwmigrate on the store to remove the corruption. Possible causes include an interruption with connection to the SAN or something deleting files within /iw-store. Neither of these we have been able to confirm but support did say that further corruption can result if the store is not dealt with.

We do not run virus scan, delete files in /iw-store nor have any reported interruptions with our SAN?

The corruption can affect EDITIONS by virtue of the fact that pointers in EDITIONS to files no longer in /iw-store cannot be resolved.

So, no definitive cause but the only way to resolve seems to be iwmigrate on the /iw-store to a new clean store.

Good luck.

Show Java Locale and ShortDateFormat from BIRT.rptdesign

Adam Stoller

I still have a case open with IWOV. They are now suggesting performing an iwmigrate on the store to remove the corruption. Possible causes include an interruption with connection to the SAN or something deleting files within /iw-store. Neither of these we have been able to confirm but support did say that further corruption can result if the store is not dealt with.

We do not run virus scan, delete files in /iw-store nor have any reported interruptions with our SAN?

The corruption can affect EDITIONS by virtue of the fact that pointers in EDITIONS to files no longer in /iw-store cannot be resolved.

So, no definitive cause but the only way to resolve seems to be iwmigrate on the /iw-store to a new clean store.

Good luck.

If the backing store was transferred (without migration) through several different versions of the product without verifying the consistency of the store - this might make sense. Even if the same server was upgraded multiple times (as opposed to bringing up a new server and copying the store over) this could happen as the backing store code has undergone a number of changes over the years and it was almost always recommended to use iwmigrate to re-create the content in a manner that conformed to the latest version of the product (theoretically the in-place upgrade of the store that takes place should be sufficient in many cases, but even that was known not to be able to take full advantage of changes in the backing store code).