On Friday 25 of February 2011 12:34:23 you wrote: > I guess pinning files on the device is possible in some way. But > Supporting FIBMAP, which internally means supporting iops->bmap vfs > interface, sounds more delicate than FIEMAP because it is actually > used to determine block location for raw-write access. The swapfile > is an example of that. > > Strictly, FIEMAP has the same risk, but in practice, we are using it > for more harmless purposes such like analyzing fragmentation or giving > hint to read-ahead tools. As a sidenote, it seems hdparm has that `--fibmap' subcommand, but it actually issues FIEMAP rather than FIBMAP ioctl. > If we can safely disable a swapfile on filesystem and we can widely > share the basic premise that "writing to the block location acquired > by FIBMAP is a very dangerous thing for log-structured filesystems or > COW filesystems", we could add it. Perhaps it would be enough if FIBMAP implementation for NILFS checked if the file has a `pin-it-down' attribute and only then returned anything other than EINVAL. Regarding pinning a file to physical location on a device: if a file is part of a snapshot, does its data or metadata ever get moved? -- dexen deVries [[[â][â]]] > how does a C compiler get to be that big? what is all that code doing? iterators, string objects, and a full set of C macros that ensure boundary conditions and improve interfaces. ron minnich, in response to Charles Forsyth http://9fans.net/archive/2011/02/90 -- To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
