Thanks a lot for your response.
I never thought it might be in a log and not flushed to disk.
Very good clue.
>>>It is not XFS problem. It is your problem ;)
Good comment. Agreed : -).
>>How are you finding and inode off disk
I have lot of code getting in to that. To explain that I have to go through
that complex part of the code to explain in detail.
Basically once we get indoe number for a given file from the available
system call, we only depending upon the XFS layout and it's structure. We
are reading super block from a particular disk offset and calculating
address for inode offset and its address on the disk and reading directly
from the disk offset. We are totally depending on XFS on disk layout.
To get very much detail , step by step , I have to go through complete code
and lot of calculation involved in this process. But it is going fine in
most of the cases except when new files are copied and all of you answered
Thanks alot for your respopnse.
On 1/15/08, David Chinner <dgc@xxxxxxx> wrote:
> On Mon, Jan 14, 2008 at 05:44:22PM +0530, Gopala Krishna wrote:
> > Hi,
> > I am seeing some strange problem with XFS and would like to know the
> > expected behavior and if it is faulty is there any patches to resolve
> > problem.
> > Problem:
> > ======
> > Basically I am extracting metadata information for a given file by
> > the inode structure from the particular disk offset (based on
> it's position
> > calculated by published inode structure and super block structure
> > information). Before reading the metada data information from the disk,
> > am calling fsync (I used to call sync, but later I changed to fsync,
> > sync is not guranteed to flush all meta data) to ensure all metadata
> > related to file is flushed to disk. Later I am reading particular disk
> > offset as per calculation. I am getting XFS magic field properly after
> > mapping to XFs inode structure. However I am not getting dimode properly
> > some cases (not all cases) and it shows 00000 even for regular file and
> > directory.
> How are you finding and reading the inode off disk?
> Dave Chinner
> Principal Engineer
> SGI Australian Software Group
[[HTML alternate version deleted]]