Question related to XFS sync , especially fsync

Question related to XFS sync , especially fsync

[Gopala Krishna]

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 the
problem.

Problem:
======
Basically I am extracting metadata information for a given file by reading
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, I
am calling fsync (I used to call sync, but later I changed to fsync, since
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 in
some cases (not all cases) and it shows 00000 even for regular file and
directory.

It is happening only when I copy new file to XFS.  But, when I unmount the
file system and remount it, everything goes fine and I could get all
expected meta data information and proper value for dimode (in the inode
structure which indicates the type of the file, i.e regular directory etc.)
.

Once I mount it back and later even if I remove the same file and copy it
back to XFS and then run my utility program, I could read mode information
properly. But If I copy different file, again I could not get dimode
properly. I have to unmount and remount to get the mode properly to make my
utility program to display information properly. Once it starts getting
proper mode value, it continues.

So I am suspecting, even after calling fsync (which says it would block
untill it flushes metadata information to disk ), is not really flushing. So
only during unmount, it flushes metadata and hence I could get dimode
properly. since after remounting , by reading metadata information , I could
get mode properly and differentiate directory or regular file, and also it
is filling magic etc. properly, I feel the data I am reading is right and
that I could compare with stat system call and ls commands.

If I am doing something wrong and no problem with XFS, then I should not get
mode field properly even after unmount/remount operation.

Is there any problem with XFS fsync? Why dimode is getting updated only
during unmount? why not when I call fsync? Because fsync says it has to
flush all meta dat to disk before existing.

Please let me know your feedback.


[[HTML alternate version deleted]]

Re: Question related to XFS sync , especially fsync

[Gopala Krishna]

Hi,
My system information:
-bash-3.00# uname -a
Linux   XXXXX         #1 SMP Thu May 17 14:00:09 UTC 2007 ia64 ia64 ia64
GNU/Linux

-bash-3.00# cat /etc/issue
Welcome to SUSE Linux Enterprise Server 10 SP1 (ia64) - Kernel \r (\l).

Thanks,
Gopal.

On 1/14/08, Gopala Krishna <gopalakrishna.n.m@gmail.com> 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 the
> problem.
>
> Problem:
> ======
> Basically I am extracting metadata information for a given file by reading
> 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, I
> am calling fsync (I used to call sync, but later I changed to fsync, since
> 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 in
> some cases (not all cases) and it shows 00000 even for regular file and
> directory.
>
> It is happening only when I copy new file to XFS.  But, when I unmount the
> file system and remount it, everything goes fine and I could get all
> expected meta data information and proper value for dimode (in the inode
> structure which indicates the type of the file, i.e regular directory
> etc.) .
>
> Once I mount it back and later even if I remove the same file and copy it
> back to XFS and then run my utility program, I could read mode information
> properly. But If I copy different file, again I could not get dimode
> properly. I have to unmount and remount to get the mode properly to make my
> utility program to display information properly. Once it starts getting
> proper mode value, it continues.
>
> So I am suspecting, even after calling fsync (which says it would block
> untill it flushes metadata information to disk ), is not really flushing. So
> only during unmount, it flushes metadata and hence I could get dimode
> properly. since after remounting , by reading metadata information , I could
> get mode properly and differentiate directory or regular file, and also it
> is filling magic etc. properly, I feel the data I am reading is right and
> that I could compare with stat system call and ls commands.
>
> If I am doing something wrong and no problem with XFS, then I should not
> get mode field properly even after unmount/remount operation.
>
> Is there any problem with XFS fsync? Why dimode is getting updated only
> during unmount? why not when I call fsync? Because fsync says it has to
> flush all meta dat to disk before existing.
>
> Please let me know your feedback.
>


[[HTML alternate version deleted]]

Re: Question related to XFS sync , especially fsync

[Gopala Krishna]

One more information:
XFS is not a root file system , but EXT3 is a root file system.

Thanks,
Gopal.


On 1/14/08, Gopala Krishna <gopalakrishna.n.m@gmail.com> wrote:
>
> Hi,
> My system information:
> -bash-3.00# uname -a
> Linux   XXXXX         #1 SMP Thu May 17 14:00:09 UTC 2007 ia64 ia64 ia64
> GNU/Linux
>
> -bash-3.00# cat /etc/issue
> Welcome to SUSE Linux Enterprise Server 10 SP1 (ia64) - Kernel \r (\l).
>
> Thanks,
> Gopal.
>
>  On 1/14/08, Gopala Krishna <gopalakrishna.n.m@gmail.com> 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 the
> > problem.
> >
> > Problem:
> > ======
> > Basically I am extracting metadata information for a given file by
> > reading 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, I am calling fsync (I used to call sync, but later I changed to fsync,
> > since 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 in
> > some cases (not all cases) and it shows 00000 even for regular file and
> > directory.
> >
> > It is happening only when I copy new file to XFS.  But, when I unmount
> > the file system and remount it, everything goes fine and I could get all
> > expected meta data information and proper value for dimode (in the inode
> > structure which indicates the type of the file, i.e regular directory
> > etc.) .
> >
> > Once I mount it back and later even if I remove the same file and copy
> > it back to XFS and then run my utility program, I could read mode
> > information properly. But If I copy different file, again I could not get
> > dimode properly. I have to unmount and remount to get the mode properly to
> > make my utility program to display information properly. Once it starts
> > getting proper mode value, it continues.
> >
> > So I am suspecting, even after calling fsync (which says it would block
> > untill it flushes metadata information to disk ), is not really flushing. So
> > only during unmount, it flushes metadata and hence I could get dimode
> > properly. since after remounting , by reading metadata information , I could
> > get mode properly and differentiate directory or regular file, and also it
> > is filling magic etc. properly, I feel the data I am reading is right and
> > that I could compare with stat system call and ls commands.
> >
> > If I am doing something wrong and no problem with XFS, then I should not
> > get mode field properly even after unmount/remount operation.
> >
> > Is there any problem with XFS fsync? Why dimode is getting updated only
> > during unmount? why not when I call fsync? Because fsync says it has to
> > flush all meta dat to disk before existing.
> >
> > Please let me know your feedback.
> >
>
>


[[HTML alternate version deleted]]

Re: Question related to XFS sync , especially fsync

[Andi Kleen]

"Gopala Krishna" <gopalakrishna.n.m@gmail.com> writes:
> ======
> Basically I am extracting metadata information for a given file by reading
> 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, I
> am calling fsync (I used to call sync, but later I changed to fsync, since
> sync is not guranteed to flush all meta data) 

sync is guaranteed to flush all metadata. But it has other problems
like livelocks.

 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 in
> some cases (not all cases) and it shows 00000 even for regular file and
> directory.

I suspect it's flushed to the log only. You could probably write some other
metadata until the log is completely full and fsync it, then eventually
the first change should be guaranteed to be flushed to the rest of 
the disk.

> If I am doing something wrong 

Well yes it sounds certainly weird what you're attempting.

-Andi

Re: Question related to XFS sync , especially fsync

[Olaf Frączyk]

On Mon, 2008-01-14 at 17:44 +0530, Gopala Krishna wrote:
> So I am suspecting, even after calling fsync (which says it would block
> untill it flushes metadata information to disk ), is not really flushing. So
> only during unmount, it flushes metadata and hence I could get dimode
> properly. since after remounting , by reading metadata information , I could
> get mode properly and differentiate directory or regular file, and also it
> is filling magic etc. properly, I feel the data I am reading is right and
> that I could compare with stat system call and ls commands.
The metadata are put in log. So they are on disk. Just not in the place
you expect them to find.
> 
> If I am doing something wrong and no problem with XFS, then I should not get
> mode field properly even after unmount/remount operation.
At remount the log is replayed and the metadata are in the place where
you expect them to be.
> 
> Is there any problem with XFS fsync? Why dimode is getting updated only
> during unmount? why not when I call fsync? Because fsync says it has to
> flush all meta dat to disk before existing.
And it does.
It is not XFS problem. It is your problem ;)

BTW, the GRUB does similiar thing. And many people reported problems
about it.

Regards,

Olaf

***** SUSPECTED SPAM ***** Re: Question related to XFS sync , especially fsync

[Matthias Schniedermeyer]

On 14.01.2008 17:44, 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 the
> problem.
> 
> Problem:
> ======

...

The man-page "xfs_freeze" at least reads like it does what you want, 
i.e. it flushes everything(tm).




Bis denn

-- 
Real Programmers consider "what you see is what you get" to be just as 
bad a concept in Text Editors as it is in women. No, the Real Programmer
wants a "you asked for it, you got it" text editor -- complicated, 
cryptic, powerful, unforgiving, dangerous.

Re: Question related to XFS sync , especially fsync

[Chris Wedgwood]

On Mon, Jan 14, 2008 at 05:44:22PM +0530, Gopala Krishna wrote:

> Is there any problem with XFS fsync? Why dimode is getting updated
> only during unmount? why not when I call fsync? Because fsync says
> it has to flush all meta dat to disk before existing.

it's probably in the log

if you must poke about under the fs like this, try doing
freeze/unfreeze (this is what i suggested to the grub people years
ago, but i'm not sure it ever made it upstream)

Re: Question related to XFS sync , especially fsync

[David Chinner]

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 the
> problem.
> 
> Problem:
> ======
> Basically I am extracting metadata information for a given file by reading
> 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, I
> am calling fsync (I used to call sync, but later I changed to fsync, since
> 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 in
> 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?

Cheers,

Dave.
-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group

Re: Question related to XFS sync , especially fsync

[Gopala Krishna]

Hi All,
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
for that.

Thanks alot for your respopnse.

-Gopal.

On 1/15/08, David Chinner <dgc@sgi.com> 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
> the
> > problem.
> >
> > Problem:
> > ======
> > Basically I am extracting metadata information for a given file by
> reading
> > 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,
> I
> > am calling fsync (I used to call sync, but later I changed to fsync,
> since
> > 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
> in
> > 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?
>
> Cheers,
>
> Dave.
> --
> Dave Chinner
> Principal Engineer
> SGI Australian Software Group
>


[[HTML alternate version deleted]]

Re: Question related to XFS sync , especially fsync

[Eric Sandeen]

Gopala Krishna wrote:
> Hi All,
> 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.

Can I ask why you are doing this? :)

-Eric

Re: Question related to XFS sync , especially fsync

[Nathan Scott]

On Tue, 2008-01-15 at 09:18 -0600, Eric Sandeen wrote:
> 
> > 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.
> 
> Can I ask why you are doing this? :)
> 

This would be good to know.  If you absolutely must use inode numbers
instead of path names, you should use the "by-handle" interface (like
xfsdump, xfs_fsr, etc) and not use the ondisk structures directly -
doing so is always "broken by design" and you'll get little sympathy
here for doing so. :)

cheers.

-- 
Nathan

Re: Question related to XFS sync , especially fsync

[Gopala Krishna]

Is there any XFS call from user level to flush metadata  for a given file or
complete log  to disk?

Thanks,
Gopal.

On 1/16/08, Nathan Scott <nscott@aconex.com> wrote:
>
> On Tue, 2008-01-15 at 09:18 -0600, Eric Sandeen wrote:
> >
> > > 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.
> >
> > Can I ask why you are doing this? :)
> >
>
> This would be good to know.  If you absolutely must use inode numbers
> instead of path names, you should use the "by-handle" interface (like
> xfsdump, xfs_fsr, etc) and not use the ondisk structures directly -
> doing so is always "broken by design" and you'll get little sympathy
> here for doing so. :)
>
> cheers.
>
> --
> Nathan
>
>


[[HTML alternate version deleted]]

Re: Question related to XFS sync , especially fsync

[Gopala Krishna]

Thank you Chris.
While  replying  to Eric, I mentioned why we are doing that. We are
basically providing interfaces to back up applications in a pure storage
environment that deals with the  back up at block level (sector level) and
hence depending upon different file system, we need to get information about
file like it's extent information and associated block numbers etc. To
extract these there is no system call and hence we are depending on disk
layout published by file system vendors and the header file provided by
them.
If there is a user level system call to deal with the extent information
etc, we can use , but many file system is not providing that. Basically if
we give file it should eb in aposition to display metadata informations
including extents and corresponding logical block numbers and device
offsets.

I have to do it programitically and hence if I have some system call rather
than command, that would be helpful. Freeze/unfreeze is a command it seems
right?

Thanks,
Gopal.





On 1/16/08, Chris Wedgwood <cw@f00f.org> wrote:
>
> On Wed, Jan 16, 2008 at 12:13:54PM +0530, Gopala Krishna wrote:
>
> > Is there any XFS call from user level to flush metadata for a given
> > file or complete log to disk?
>
> like a said earlier, try freeze/unfreeze
>
> you've not explained what you're doing (well, why you're doing it)
>
> it sounds very problematic by design
>


[[HTML alternate version deleted]]

Re: Question related to XFS sync , especially fsync

[Iustin Pop]

On Wed, Jan 16, 2008 at 12:55:17PM +0530, Gopala Krishna wrote:
> If there is a user level system call to deal with the extent information
> etc, we can use , but many file system is not providing that. Basically if
> we give file it should eb in aposition to display metadata informations
> including extents and corresponding logical block numbers and device
> offsets.
> 
> I have to do it programitically and hence if I have some system call rather
> than command, that would be helpful. Freeze/unfreeze is a command it seems
> right?

Well, most commands are backed by a system call, right? For example,
strace xfs_freeze to see what system calls it does. IIRC, only xfs_db
has to access the raw device.

For the block mapping, look at xfs_bmap (and its backend xfs_io), which
should do exactly what you want.

iustin

Re: Question related to XFS sync , especially fsync

[Gopala Krishna]

You are right and that is the approach I will follow if there is no direct
system call.

Thanks,
Gopal.


On 1/16/08, Iustin Pop <iusty@k1024.org> wrote:
>
> On Wed, Jan 16, 2008 at 12:55:17PM +0530, Gopala Krishna wrote:
> > If there is a user level system call to deal with the extent information
> > etc, we can use , but many file system is not providing that. Basically
> if
> > we give file it should eb in aposition to display metadata informations
> > including extents and corresponding logical block numbers and device
> > offsets.
> >
> > I have to do it programitically and hence if I have some system call
> rather
> > than command, that would be helpful. Freeze/unfreeze is a command it
> seems
> > right?
>
> Well, most commands are backed by a system call, right? For example,
> strace xfs_freeze to see what system calls it does. IIRC, only xfs_db
> has to access the raw device.
>
> For the block mapping, look at xfs_bmap (and its backend xfs_io), which
> should do exactly what you want.
>
> iustin
>


[[HTML alternate version deleted]]

Re: Question related to XFS sync , especially fsync

[Christoph Hellwig]

On Wed, Jan 16, 2008 at 12:55:17PM +0530, Gopala Krishna wrote:
> While  replying  to Eric, I mentioned why we are doing that. We are
> basically providing interfaces to back up applications in a pure storage
> environment that deals with the  back up at block level (sector level) and
> hence depending upon different file system, we need to get information about
> file like it's extent information and associated block numbers etc.

This basically can't work.  If you do a plain block based backup you
need to freeze the filesystem first and then either backup through a
newly created snapshot or the raw device.  Alternatively you can do
file-based backups assisted by the bulkstat interface as done by
xfsdump.  If you try to mix the two layers you get into deep trouble
due to various issues:

 - knowledge of the disk format.  The ondisk format can change anytime
   and will break your application.  And yes, additions to the ondisk
   format do happen quite frequently.
 - no coherency between the filesystem and the block device node.  This
   is especially true for backup applications which use the buffered
   block device nodes because there is a real-life chance that stale
   cache is around
 - no guarantee that the ondisk image is actually update.  XFS like
   most other current filesystems uses an intent log to provide
   reliabily and sync is only guaranteed to push updates into the log
   but not actually write it back to it's "normal" location on disk.

In short what you're trying to do is a road to disaster, so don't do it!

Note that the problems apply to any filesystem in one way or another,
not just XFS.

Re: Question related to XFS sync , especially fsync

[Gopala Krishna]

Thanks for the suggestions!.  I will relook at the my idea and
design....implemetation. As of now what we are doing is in experimental
stage.

Thanks,
Gopal.


On 1/16/08, Christoph Hellwig <hch@infradead.org> wrote:
>
> On Wed, Jan 16, 2008 at 12:55:17PM +0530, Gopala Krishna wrote:
> > While  replying  to Eric, I mentioned why we are doing that. We are
> > basically providing interfaces to back up applications in a pure storage
> > environment that deals with the  back up at block level (sector level)
> and
> > hence depending upon different file system, we need to get information
> about
> > file like it's extent information and associated block numbers etc.
>
> This basically can't work.  If you do a plain block based backup you
> need to freeze the filesystem first and then either backup through a
> newly created snapshot or the raw device.  Alternatively you can do
> file-based backups assisted by the bulkstat interface as done by
> xfsdump.  If you try to mix the two layers you get into deep trouble
> due to various issues:
>
> - knowledge of the disk format.  The ondisk format can change anytime
>   and will break your application.  And yes, additions to the ondisk
>   format do happen quite frequently.
> - no coherency between the filesystem and the block device node.  This
>   is especially true for backup applications which use the buffered
>   block device nodes because there is a real-life chance that stale
>   cache is around
> - no guarantee that the ondisk image is actually update.  XFS like
>   most other current filesystems uses an intent log to provide
>   reliabily and sync is only guaranteed to push updates into the log
>   but not actually write it back to it's "normal" location on disk.
>
> In short what you're trying to do is a road to disaster, so don't do it!
>
> Note that the problems apply to any filesystem in one way or another,
> not just XFS.
>
>


[[HTML alternate version deleted]]

Re: Question related to XFS sync , especially fsync

[Mark Goodwin]

Gopala,

it sounds like you want something like NDMP. Check that out first.

-- Mark

Gopala Krishna wrote:
> Thanks for the suggestions!.  I will relook at the my idea and
> design....implemetation. As of now what we are doing is in experimental
> stage.
> 
> Thanks,
> Gopal.
> 
> 
> On 1/16/08, Christoph Hellwig <hch@infradead.org> wrote:
>> On Wed, Jan 16, 2008 at 12:55:17PM +0530, Gopala Krishna wrote:
>>> While  replying  to Eric, I mentioned why we are doing that. We are
>>> basically providing interfaces to back up applications in a pure storage
>>> environment that deals with the  back up at block level (sector level)
>> and
>>> hence depending upon different file system, we need to get information
>> about
>>> file like it's extent information and associated block numbers etc.
>> This basically can't work.  If you do a plain block based backup you
>> need to freeze the filesystem first and then either backup through a
>> newly created snapshot or the raw device.  Alternatively you can do
>> file-based backups assisted by the bulkstat interface as done by
>> xfsdump.  If you try to mix the two layers you get into deep trouble
>> due to various issues:
>>
>> - knowledge of the disk format.  The ondisk format can change anytime
>>   and will break your application.  And yes, additions to the ondisk
>>   format do happen quite frequently.
>> - no coherency between the filesystem and the block device node.  This
>>   is especially true for backup applications which use the buffered
>>   block device nodes because there is a real-life chance that stale
>>   cache is around
>> - no guarantee that the ondisk image is actually update.  XFS like
>>   most other current filesystems uses an intent log to provide
>>   reliabily and sync is only guaranteed to push updates into the log
>>   but not actually write it back to it's "normal" location on disk.
>>
>> In short what you're trying to do is a road to disaster, so don't do it!
>>
>> Note that the problems apply to any filesystem in one way or another,
>> not just XFS.
>>
>>
> 
> 
> [[HTML alternate version deleted]]
> 
> 

-- 

  Mark Goodwin                                  markgw@sgi.com
  Engineering Manager for XFS and PCP    Phone: +61-3-99631937
  SGI Australian Software Group           Cell: +61-4-18969583
-------------------------------------------------------------

Re: Question related to XFS sync , especially fsync

[Martin Steigerwald]

Am Mittwoch 16 Januar 2008 schrieb Mark Goodwin:
> Gopala,
>
> it sounds like you want something like NDMP. Check that out first.

Is there an open source implementation available for this protocol? Would 
be interesting to know.

-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7

Re: Question related to XFS sync , especially fsync

[Mark Goodwin]

Martin Steigerwald wrote:
> Am Mittwoch 16 Januar 2008 schrieb Mark Goodwin:
>> Gopala,
>>
>> it sounds like you want something like NDMP. Check that out first.
> 
> Is there an open source implementation available for this protocol? Would 
> be interesting to know.

See http://www.ndmp.org for the FAQ, spec, etc. THere is a download area
with an SDK but no open source version that I know of.

Perhaps a new project is born ;-)

Cheers

-- 

  Mark Goodwin                                  markgw@sgi.com
  Engineering Manager for XFS and PCP    Phone: +61-3-99631937
  SGI Australian Software Group           Cell: +61-4-18969583
-------------------------------------------------------------

Re: Question related to XFS sync , especially fsync

[Andi Kleen]

"Gopala Krishna" <gopalakrishna.n.m@gmail.com> writes:

> we need to get information about
> file like it's extent information and associated block numbers etc.
 To
> extract these there is no system call 

Actually there is the FIOBMAP ioctl for data blocks. e.g. it's used by
boot loaders like lilo to create a block map to read a file without
knowledge of the file system. Should work on all file systems that
support lilo.

It won't give you information about metadata blocks though.

-Andi

Re: Question related to XFS sync , especially fsync

[David Chinner]

On Thu, Jan 17, 2008 at 02:25:00AM +0100, Andi Kleen wrote:
> "Gopala Krishna" <gopalakrishna.n.m@gmail.com> writes:
> 
> > we need to get information about
> > file like it's extent information and associated block numbers etc.
>  To
> > extract these there is no system call 
> 
> Actually there is the FIOBMAP ioctl for data blocks. e.g. it's used by
> boot loaders like lilo to create a block map to read a file without
> knowledge of the file system. Should work on all file systems that
> support lilo.

On XFS, you should use XFS_IOC_GETBMAPX. It's much faster
and returns lots more information than FIOBMAP. It can also
be used on the attribute fork of the inode, and it works on
directories as well.

Cheers,

Dave.
-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group