SEEK_HOLE or FIEMAP?
SEEK_HOLE or FIEMAP?
Posted Dec 7, 2007 10:25 UTC (Fri) by etienne_lorrain@yahoo.fr (guest, #38022)In reply to: SEEK_HOLE or FIEMAP? by giraffedata
Parent article: SEEK_HOLE or FIEMAP?
<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.
Posted Dec 13, 2007 13:28 UTC (Thu)
by RobLucid (guest, #49530)
[Link]
SEEK_HOLE or FIEMAP?
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.