On Thu, Nov 22, 2007 at 07:56:20PM +0000, Alan Cox wrote:> > probably principle of least privilege; the location on physical media> > for a file is clearly something internal to the OS, and non-trusted> > users normally don't have any business knowing that. > FIBMAP isn't correctly locked against misuse, and that requires FIBMAP is> safe against truncate and relocation. There was thread on l/k about this> a month ago or so.> > Its also the wrong API (32bit, no notion of extents, compression etc)

The right approach would be to create a new syscall, and a new entrypoint in the inode operations table, and filesystems could providesupport for the new system call as their bmap code was audited forcorrectness.

For bonus points the new interface would also provide make it moreefficient for filesystems to return information about extents. (i.e.,Not only is logical block 150 mapped to physical block 5550, it ispart of an 200 block extent starting at logical block 0 to physicalblock 5400.)