Re: Putting core.img anywhere

["Javier Martín" <lordhabbit@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 4567 bytes --]

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

[-- Attachment #2: Esta parte del mensaje está firmada digitalmente --]
[-- Type: application/pgp-signature, Size: 827 bytes --]