On Fri, 25 Feb 2011 09:02:46 +0100, dexen deVries wrote: > On Friday 25 of February 2011 01:21:53 you wrote: > > Just thinking about it fast, NILFS2 is a filesystem that wraps around > > the disk forever and LILO writes a bitmap of where the kernel image > > is. So if NILFS moves the image then LILO is at lost and will load > > some data which is not the kernel instead. A fast guess I would say > > using LILO on NILFS is impossible by design. > > That's a good point, thanks. > > A dirty hack comes to my mind, back from the days of DOS: files marked with > `system' attribute were not moved during defrag (important for io.sys & > msdos.sys). Perhaps using some sensible attribute (i? t? a new one?) would > prevent nilfs_cleanerd from moving the file? > > Would require implementing attributes on NILFS, thou. 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. 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. Regards, Ryusuke Konishi -- 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
