| |||||||||||||
SEEK_HOLE or FIEMAP?SEEK_HOLE or FIEMAP?Posted Dec 6, 2007 15:10 UTC (Thu) by etienne_lorrain@yahoo.fr (guest, #38022)Parent article: SEEK_HOLE or FIEMAP?
> One might argue that anybody who wants to separate holes and data in > a file can already do so with the FIBMAP ioctl() command. Such an implementation at: http://www.mirrorservice.org/sites/download.sourceforge.n... executable at: http://www.mirrorservice.org/sites/download.sourceforge.n... That can be used to count the level of fragmentation of a filesystem, with some interresting results. The main problem is that some filesystems do not implement it correctly or at all (so LILO or Gujin cannot be installed on them). The other problem, for the case of a bootloader, is that it does not give the position of the data in the disk but in the device, and there is a big difference when the device is a RAID or LVM. The thing the bootloader has to do is to register where its own code/data are on disk to be able to load them without the kernel support, and to have only one file, to write the position of the end of the file at the beginning of itself, so to have block allocated to disk before the write into the file is finished - possible but tricky.
(Log in to post comments)
SEEK_HOLE or FIEMAP? Posted Dec 7, 2007 1:55 UTC (Fri) by giraffedata (subscriber, #1954) [Link] It's much cleaner to have the boot loader use the proper directories, block maps, etc. to access the filesystem. GRUB does this. In its usual deployment, GRUB still has the problem because that code that knows how to access the filesystem is in the filesystem, and the only way GRUB knows to find it is with built-in block numbers. But it's possible to put that code outside the filesystem, in an area of disk reserved for that purpose, and then the world is as it should be. You don't need any special kernel interfaces at boot loader installation time, and you don't have to take care to keep the blocks from moving after you've installed the boot loader.
SEEK_HOLE or FIEMAP? Posted Dec 7, 2007 10:25 UTC (Fri) by etienne_lorrain@yahoo.fr (guest, #38022) [Link] <rant> > It's much cleaner to have the boot loader use the proper directories, block maps, etc. to access the filesystem. GRUB does this. So does Gujin - smaller number of filesystem supported, I have to say. > In its usual deployment, GRUB still has the problem because that code that knows how to access the filesystem is in the filesystem, and the only way GRUB knows to find it is with built-in block numbers. So does Gujin. > But it's possible to put that code outside the filesystem, in an area of disk reserved for that purpose, and then the world is as it should be. By default Gujin puts that code at the end of the disk, outside of any filesystem, but it not always available depending on the tool used to create the partitions (Linux tools are used to fill the whole disk - not leaving a single unallocated sector for the bootloader). </rant> Doesn't change that it would be nice to have a kernel interface which maps the device block into a hard disk block, for that part of the bootloader which shall not move when it is on a filesystem (RAID and LVM problem). It would also be nice to have an interface to tell the filesystem that this file is the boot code - there is an inode reserved for that in EXT2/3FS but no way to use it.
SEEK_HOLE or FIEMAP? Posted Dec 13, 2007 13:28 UTC (Thu) by RobLucid (guest, #49530) [Link] Wonder why good ole' partitions are out of fashion? Rather than having the ability for applications to do nasty things and become dependant on physical block numbers, which prevent copying of files around. You could use a raw partition, and then copy the blocks into known offsets from the beginning of the partition. This seems much simpler. Presumbably a BootFS, with a boot loader friendly structure might also be a robust alternative and avoid duplication, of files in the raw partition approach.
|
|||||||||||||