El lun, 21-07-2008 a las 11:13 +0200, Jean-Christophe Haessig escribió: > Le dimanche 20 juillet 2008 à 17:06 +0200, Javier Martín a écrit : > Hi, > > > This should have been fixed by the transition to LZMA as the compression > > algorithm for PC - core.img should now be under 32K and embeddable in > > the 32256 bytes available before the first MBR partition. > > As I stated earlier my disks are not DOS-partitioned (e.g. > pvcreate /dev/hda). I didn't want to have one useless level of the old > DOS partition scheme since LVM already does the job (better). Well, I can't dissent on that, but then your whole HD, from the first to the last LBA block, is full with data that can move at LVM's whim.
> > > However, I can ensure that my /boot logical volume is not too far from > > > the beginning of the disk, and I thought about the following algorithm : > > How can you do so? Is there a way to force LVM to put a certain LV > > within a particular region of a PV within the VG? > > Short answer : yes. Longer answer : LVM does not (yet) gratuitously move > LVs among PVs, LVs stay where they have been created and when you create > a LV on an empty PV, it is normally allocated at the beginning of the > disk in continuous extents. And yes, using pvmove you can move data > anywhere you like. You can move a LV to a certain PV, but apart from that there is not a point in the LVM "specification" or "documentation" that I've seen that can allow you to move data into _specific_ PEs _and_ keep it there: pvmove does the former but does not guarantee they will still be there in, say, a week: the only way I can think of would be to tie the /boot LV to a PV near the start of the disk, but as you said, then you wouldn't be in this dilemma. > > Theoretically it would work, but this is heavy duty work we're talking > > about - potentially reading the whole disk if a single file has moved > > due to, say, a defrag. > > That's why I included the random-number-chain feature. If the file is > accidentally moved, it can still be found by the bootsector. > Additionnally, GRUB could display a message about this to the user, > telling him that it is in degraded mode and that he should re-run some > utility to reindex the file. > As for reading the entire disk, an arbitrary upper limit could be put to > force the boot sector to fail. First of all, LVM2 LVs don't have to keep consistency iIrc: its PEs can be (though usually aren't) scattered all over the VG PVs, which means that part of core.img could be in LBA blocks 300-330 but the other fragment might be in blocks 814567-814592. In the worst case, your system might have to read the whole disk _once per block_ in core.img, which is about 50 blocks long. That might be a _big_ hit. If that weren't enough, all your system would have to fit in the already-cramped bootsector image, since you said that there is not a single block in the HD available for embedding. In fact, do you know if LVM leaves space in block #0 (its "superblock") for boot code like GRUB's? If not, you can't even install GRUB, since there is no place to install it to. A suggestion: if you want to keep your no-partitions schema, why don't you boot from a floppy, a CD or a USB pendrive? You would save a lot of headaches... > > It would work as long as the filesystem stores 512-byte blocks together. > > However, with tail-packing features _might_ pose a problem; and > > filesystems that altered the data in any way, like NTFS compression or > > some kind of inline checksumming/signing would be a no-go. > > Sure, but who would use NTFS for their /boot ? Most filesystems should > work already, I think, otherwise even LILO couldn't work… The same kind of geek* that does not partition his hard drives ;) Besides, I was only using NTFS compression as an example: extN filesystems also have a compression feature (though it's not very used). Any other kind of inline addition/alteration of the data on store by the FS (like the addition of a checksum each 128 bytes or so) or the breakage of the assumption that _our_ blocks are still block-aligned on the filesystem would break your system too. Nevertheless, those assumptions, particularly the latter, usually hold, so your system is already quite robust as things go. Cheers! Habbit * I did the same once, formatting a whole disk reiserfs for a temporary storage addition. I've also partitioned an OLD pc laptop with GPT, so yeah, I kinda like experimenting with partitions
signature.asc
Description: Esta parte del mensaje está firmada digitalmente
_______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
