Chris Mason wrote:
On Sat, 27 Oct 2007 18:57:06 +0100
Anton Altaparmakov <aia21@xxxxxxxxx> wrote:
Hi,
->bmap is ugly and horrible! If you have to do this at the very
least please cause ->bmap64 to be able to return error values in case
the file system failed to get the information or indeed such
information does not exist as is the case for compressed and
encrypted files for example and also for small files that are inside
the on-disk inode (NTFS resident files and reiserfs packed tails are
examples of this).
And another of my pet peeves with ->bmap is that it uses 0 to mean
"sparse" which causes a conflict on NTFS at least as block zero is
part of the $Boot system file so it is a real, valid block... NTFS
uses -1 to denote sparse blocks internally.
Reiserfs and Btrfs also use 0 to mean packed. It would be nice if there
was a way to indicate your-data-is-here-but-isn't-alone. But that's
more of a feature for the FIEMAP stuff.
I hadn't heard of FIEMAP, so I went back and read the thread from
April/May. It seems that this is a much better approach than
introducing a FIBMAP64.
What ever happened with this proposal?
Mike Waychison
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
