Chris Mason wrote:
On Sat, 27 Oct 2007 18:57:06 +0100
Anton Altaparmakov <[email protected]> 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-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
