Nathan Scott <nathans@xxxxxxx> writes:
> On Mon, Feb 11, 2002 at 11:22:00PM +1000, monkeyiq wrote:
> > Hi,
> > With this little change one can use
> > $ ./xfs_bmap -x ~/tmp/holes
> > <?xml version="1.0"?>
> > <extentlist>
> > <extent id="0" type="hole" blocks="192" file-offset-start="0"
> > file-offset-end="191" >
> > </extent>
> > <extent id="1" blocks="8" file-offset-start="192" file-offset-end="199"
> > allocation-group="2" allocation-offset-start="236328"
> > allocation-offset-end="236335" >
> > </extent>
> > </extentlist>
> Now that I've seen the code, it seems this could be done with
> a 4/5 line perl/awk script which parses `xfs_bmap -vv /tmp/foo`
> rather than modifying the existing program at all. Thoughts?
> xfs_bmap output is quite regular, so it shouldn't be too hard..
Well, the main reason I was adding this was to avoid parsing output
to get output, though that is very possible. I dont see that the script
would be that much simpler than the xml output function by the time one
takes into account script readability and special cases like holes in
files. Also because the XML output is not ment for direct tty output
one can add in any other extent related info that can be found, including
for example if an extent is preallocation related which is not in -v at
this point. Also if there is other stuff that goes into bmv_oflags in
the future then that can become a new attribute in the XML.
> And when someone wants a <xml version="2.0"> output or some
> other trendy output format, only the script would need changes.
I am no expert on what XML 2.0 will offer, but one could also use
XSLT to make it from the 1.0 document though I don't see a version
2.0 sweeping the land.
In the end, I don't mind much either way. I'm not out to ruffle people
up about putting XML everywhere. If folks don't think that having a XML
output option is correct or desirable in xfs_bmap then maybe it should
go someplace else.