A while back I was talking about adding preallocation support to ferris. I didn't get around to adding it at the time, though the doco seems much better now and I have an application which would be
A while back I was talking about adding preallocation support to ferris. I didn't get around to adding it at the time, though the doco seems much better now and I have an application which would be g
I had a look at bmap, very nice. BTW as an aside the man pages dont document -p or -V (and -v though that one is not even in bmap --help) for bmap [xfsprogs-1.3.17-0]. After looking through xfs_mkfil
After looking at the xfs_bmap code a little and working out my next move I noticed in xfs_fs.h struct getbmapx { __s64 bmv_offset; /* file offset of segment in blocks */ __s64 bmv_block; /* starting
It's still not well tested on Linux... I'll check in a fix soon for a fairly serious bug in RT - if you open an RT file and write to it without O_DIRECT, it writes to the main data device, not the RT
Would this introduce a new dependency on libxml? If so, it shouldn't be added into the xfsprogs xfs_bmap - I'd suggest making a new program based on xfs_bmap.c (its only ~400 lines or so), add the ne
Ok, so it deserves the experimental tag then ;) not yet, I usually ask if there is much/any interest in patches to other folks code before I create the patch. I don't like maintaining forks of code s
No. I was just going to build the xml using snprintf() not the DOM interface. So there would only be a slight increase in exe size due to code similar to the -v code being there to make XML. there wo