Martin Jambor writes: > Thanks for your reply, I found the the following thing interesting on its > own: > > On 4/7/05, Nikita Danilov <[EMAIL PROTECTED]> wrote: > > Consider tools like LILO that want stable block numbers for certain > > files. In reiserfs (both v3 and v4) there is an ioctl that disables > > relocation for a given file. Besides, I do not think ->bmap() is useless > > even when block numbers are volatile, for one thing it allows user level > > to track how file is laid out (for example, to measure fragmentation). > > I tried to google out what behaviour lilo requires filesystems to > exhibit without much success... is that information available > somnewhere I din't look? Is that simple enought to be explained here?
As opposed to, say, GRUB, LILO doesn't parse file system layout at the boot time. Instead it remembers in what blocks kernel image is stored. This assumes following properties of the file system: - unit of disk space allocation for the kernel image file is block. That is, optimizations like UFS fragments or reiserfs tails are not applied, and - blocks that kernel image is stored into are real disk blocks (i.e., there is a way to disable "delayed allocation"), and - kernel image file is not relocated, i.e., data are not moved into another blocks on the fly. Currently the only file system that doesn't satisfy any of there requirements is reiserfs, and it has special ioctl REISERFS_IOC_UNPACK that forces LILO friendly behaviour for a specified file: no tails, no delayed allocation, and no relocation. LILO detects when kernel image is on reiserfs and calls that ioctl. > > TIA > > Martin Nikita. - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
